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Abstract 



This paper describes an approach for verifying programs in the presence of data 
abstraction and information hiding, which are key features of modern program- 
ming languages with objects and modules. The paper focuses on the property of 
modular soundness, that is, the property that the separate verifications of the indi- 
vidual modules of the program suffice to ensure the correctness of the composite 
program. The paper introduces a new specification language construct, the ab- 
straction dependency, and argues that it is needed to achieve modular soundness 
in the presence of data abstraction and information hiding. This paper discusses 
in detail two varieties of abstraction dependencies: static and dynamic. The paper 
also presents a new technical definition of modular soundness as a monotonicity 
property of verifiability with respect to scope and uses this technical definition 
to formally prove the modular soundness of a programming discipline for static 
dependencies. 
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The romance of the precise is not the elision 
Of the tired romance of imprecision. 
It is the ever-never-changing same, 
An appearance of Again, the diva-dame. 

— Wallace Stevens 

0 Introduction 

This paper describes an approach for verifying programs in the presence of data 
abstraction, object types, and information hiding. The genesis of this work was the 
Extended Static Checking project (ESC) [8], which applies program verification 
technology to systems programs written in Modula-3. The aim of ESC is not to 
prove full functional correctness, but to prove the absence of common errors, such 
as array index errors, nil dereference errors, race conditions, deadlocks, etc. 

One of the biggest problems we encountered in the ESC project is that the 
verification methodology we know from the literature does not seem to apply 
to the systems programs in the Modula-3 libraries. The problem is not that the 
programs use low-level tricks or unsafe code; the problem is that the programs use 
patterns of modularization and data abstraction that are richer than those treated 
in the verification literature. This is not an artifact of Modula-3, but would apply 
to any modern object-oriented language. 

The data abstraction technology we know from the literature extends and re- 
fines the seminal paper on data abstraction by C.A.R. Hoare in 1972 [18]. In 
particular, Hoare and all subsequent treatments that we know impose the require- 
ment that all of the concrete variables used to represent an abstraction must be 
declared in the same module. This requirement is too strict: if it were applied 
to the Modula-3 libraries, many small modules would have to be combined, with 
a loss of desirable information-hiding. Writing specifications is supposed to im- 
prove the structure of a program, so it is ironic that standard treatments of data 
abstraction are incompatible with good modularization. Therefore, in this paper 
we weaken Hoare's requirement and allow the concrete variables used to represent 
an abstraction to be divided among several modules. 

A key technical challenge is to check modules where an abstract variable is 
visible, some of the concrete variables used to represent it are visible, but the 
abstraction representation function is not visible. To meet this challenge, we in- 
troduce a new specification construct called the abstraction dependency. This 
construct specifies that an abstraction connection exists between the variables, but 
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does not specify the actual abstraction representation, which can be confined to 
a more private scope. There are different types of dependencies, and these types 
produce a useful taxonomy of the patterns of abstraction in modular software. 

Abstraction dependencies give the programmer considerable freedom in ar- 
ranging the declarations of abstract variables, concrete variables, abstraction rep- 
resentation functions, and dependencies among the modules of a program. Too 
much freedom: without further restrictions, we would lose the property of modu- 
lar soundness, that is, the property that the separate verifications of the individual 
modules of the program suffice to ensure the correctness of the composite pro- 
gram. We therefore impose several requirements, called modularity requirements, 
and argue that modular verification is sound for programs that meet the modularity 
requirements. 

1 On the need for data abstraction 

Before we get into the details of our generalization, we set the stage by reviewing 
the role of data abstraction in modular verification. 

To check that a large program does what it is supposed to do, we must study 
it piece by piece. Nobody's short-term memory is big enough to hold all the 
details of a large program. If the checking effort (formal or informal) is to be 
manageable, we cannot afford to re-examine the body of a procedure for every one 
of its calls. This is the reason for writing specifications, formal or informal. Given 
specifications, we check that each procedure meets its specification, assuming that 
the procedures it calls meet theirs. 

This checking process is called modular verification, and for simple program- 
ming languages it has been understood since C.A.R. Hoare's work on axiomatic 
semantics in the 1960s. (As long as the bulk of the verification is done modularly, 
we do not exclude simple link- time checks, such as the check that each proce- 
dure is implemented somewhere in the program.) The central goal of this paper is 
to understand modular verification in the presence of two modern programming 
features: data abstraction and information hiding. 

A procedure specification includes a precondition and a postcondition. The 
precondition is the part of the contract to be fulfilled by the caller of the proce- 
dure, and the postcondition is the part of the contract to be fulfilled by the pro- 
cedure implementation. But precondition and postcondition are not enough: the 
specification also includes a "modifies list" that limits which variables the pro- 
cedure is allowed to modify. Without the modifies list, the contract would allow 
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a procedure to have arbitrary side effects on any variable not constrained by the 
postcondition, which would make the contract useless to the client. 

It is possible to view the modifies list as syntactic sugar for extra conjuncts 
in the postcondition, asserting that every variable not mentioned in the modifies 
list is unchanged. That is, in a program with three variables x , y , and z , the 
specification 

requires P modifies x ensures Q 

could be "desugared" into 

requires P ensures Q/\y=y'/\z = z 

in which primed variables denote post-values and unprimed variables denote pre- 
values. We cannot, however, use this desugaring to pretend that each procedure 
specification consists of a precondition and postcondition only. The reason is that, 
in modular verification, we never know, when verifying a procedure, what the 
set of all variables in the final program will be. Perhaps x , y , and z are the 
only variables visible where the procedure is declared, but more variables may be 
visible where the procedure is called. Therefore, in this paper we take the view 
that the modifies list is an integral part of the specification. Although we will 
rewrite modifies lists, the rewriting is different for different scopes. 

Unfortunately, and perhaps surprisingly to those who have used verification 
more in principle than in practice, the methodology described so far is still inad- 
equate. In many cases, it would be preposterous to try to list every piece of state 
that might be modified by a call to a procedure. For example, what would be the 
list for the put char procedure from the C standard I/O library? What put char 
does is simply write a character to output, but anybody who has implemented an 
I/O system will be aware that the list of what can be modified during the execution 
of a call to put char is very long. It includes, for example, the I/O buffers, the 
internal state of the device drivers for the disk and network, the device registers 
in these drivers, and the disk and network themselves. The minor problem is that 
this list is long; the major problem is that the variables in the list are not visible at 
the point of declaration of put char , and to make them visible would be to give 
up on information hiding, which would be to resign the game before it starts. 

The solution to this difficulty — at least the only solution that we can imagine — 
is data abstraction. Abstractly, put char modifies a single abstract variable, of a 
simple type (say, sequence of byte). All the internal state, from buffers to devices, 
must be treated as concrete state that is part of the representation of the abstract 
state. 
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Some people see data abstraction as an algorithm design methodology only, 
as a methodology for deriving an efficient algorithm from a simple algorithm by 
changing the representation of the state. We have no quarrel with their use of data 
abstraction, but our point is that data abstraction is also an essential ingredient 
in any scheme for modular verification of large systems, since it seems to be the 
only hope for writing a useful modifies list for a procedure whose implementation 
changes the system state at many levels of abstraction. 

Having identified the general idea of the solution to the put char problem as 
data abstraction, we would add that the patterns of data abstraction that arise in 
verifying put char are beyond the current state of the art of specification: we 
believe that no semantics or methodology presented in the literature is equal to 
the task. We hope this paper will be a useful step in this neglected area. 

2 Validity as an abstract variable 

The generalized data abstraction described in this paper is relevant regardless of 
whether verification is being used for full functional correctness or for more lim- 
ited aims, such as the ESC aim of verifying the absence of certain classes of errors 
only. The examples in this paper will be ESC verifications. These verifications 
tend to have a typical form, which is described in this section. 

In a typical ESC verification, we associate two abstract variables with each 
type, valid and state. The first of these records whether objects of the type 
satisfy the internal representation invariant required by the implementation, and 
the second represents the abstract value of variables of the type. 

If we were verifying full functional correctness, we would have to write many 
specifications about the state variable. But in doing extended static checking, 
we rarely say anything about the state. We aren't proving that the program meets 
its full functional specification, only that it doesn't crash. The main purpose of 
the state variable is to account for the side effects in the implementations of the 
methods, which otherwise would lead to spurious errors reported by the verifier. 
Indeed, in many ESC verifications, we don't even bother to provide the concrete 
representation for state . 

In contrast to state , the checking performed by ESC depends critically on 
valid . Most operations on an object o will have valid[o] as a precondition. The 
checker uses the concrete representation for valid to translate valid[o] into a 
concrete precondition, which it then uses in proving that the implementation of 
the operation does not cause an error. 
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In Hoare's original paper on data abstraction, the notion of a validity invariant 
was built into the methodology. Initialization was required to establish validity 
and all other operations were required to preserve it. In contrast, we consider valid 
to be an abstract variable like any other; the programmer explicitly provides valid 
as a precondition (and/or postcondition), and the implementation infers the details 
of validity in terms of the concrete state via the usual process of data abstraction. 
Our approach has several advantages over Hoare's, of which we mention one: we 
allow operations like closing a file, which destroy validity. Such operations are 
frequently essential in order to deallocate resources. 

3 Definition of notation 

This section introduces the notation and terminology that we use in the rest of the 
paper. 

Modularity. A program is a collection of declarations. Declarations introduce 
names for entities (such as types, abstract and concrete variables, and methods) 
and/or specify properties of named entities (such as subtype relationships, repre- 
sentations of abstract variables, method specifications, and method implementa- 
tions). The declarations of a program are partitioned into units (sometimes called 
interfaces and modules). The declarations in effect in a unit are its own decla- 
rations and the declarations in effect in units that it imports. If an entity E is 
declared in a unit M , it is known as M.E in importers of M and known simply 
as E within M . For example: 

unit M unit N import M 

typeT ... uses of MT... 

. . . uses of T . . . 

In this paper, we sometimes write E instead of M.E when M is clear from the 
context. 

A set of units D is called a scope if it is closed under imports, that is, if 
whenever a unit M in D imports a unit ./V , then ./V is also in D . A declaration 
is visible in a scope if it appears in one of the units in the scope. 

We use units and imports in this paper since they are simple and extremely 
general. Restrictive patterns are common in practice. For example, Modula-3 
requires that every unit be an interface unit, which can declare procedures and 
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methods but not declare implementations, or an implementation unit, which can 
declare implementations but which cannot be imported. As another example, 
CLU imposes a correspondence between units and type declarations. We have 
not imposed such restrictions in this paper, because they seem orthogonal to the 
modularity issues that we are discussing. 

Types. In this paper, we will use primitive types like int and bool , as well as 
object types and array types. Our objects are like those of Simula and Modula- 
3: they are implicitly references, and each object type has a uniquely determined 
direct supertype. More precisely, an object is either nil or a reference to a set 
of data fields and methods; a method is a procedure that will accept the object as 
its first parameter. Equality of objects is reference equality. An object type deter- 
mines the names and types of a prefix of the fields and the names and signatures 
of a prefix of the methods of its objects. 
An object type T is declared 

type T <: S 

where S is an object type declared elsewhere. This introduces the name T for 
a new object type whose direct supertype is S , meaning that T contains all the 
fields and methods of S and possibly includes other fields and methods declared 
elsewhere. The " <: 5" is optional; if omitted, S defaults to an anonymous object 
type serving as the root of the subtype hierarchy. 

Every object has a dynamic type determined when it is allocated. Every ex- 
pression has a static type determined at compile time. If v is the dynamic value 
of an expression E , v has dynamic type D , and E has static type S , then con- 
ventional static type-checking rules assure that D is a subtype of S . 

We consider a data field, abstract or concrete, to be a map from objects to 
values. Thus, where others write 

class T ={.../: int ... } 

we write 

type T 

var/: T -> int 

Also, we write f[t] where others write t.f to denote the value of the / field of ob- 
ject t . We refer to T and int as the index type and range type of / , respectively. 



6 



The class notation forces / to be co-declared with T , whereas our notation al- 
lows them to be declared independently. This generality is not problematical; in 
fact, it simplifies the semantics. 
If T is a type, we write 

array [T] 

to denote the type of (references to) arrays with element type T . If a is of type 
array|T] and is non- nil , then number(a) denotes the number of elements in a , 
and a[i] denotes element i of a for 0 < i < number(a) . To properly model the 
fact that arrays are references, we introduce the predeclared map variable elems : 
the expression elems[a] denotes the sequence of elements referred to by an ar- 
ray a . For example, a = b means that a and b reference the same sequence, 
while elems[a] = elems[b] means that the sequences referenced have the same 
elements. In fact, a[i] is shorthand for elems[a][i] . 

If T is an object type, new(T) allocates and returns a new object of dynamic 
type T . For any type T , new(7\ n) allocates and returns a new array of dynamic 
type array [T] and of length n . 

A method m for type T is declared by 

proc m(t: T, . . . args . . .): R 
requires P 
modifies w 
ensures Q 

where in the signature " (t: T, . . . args . . .): R ", T is an object type, t is the self 
parameter, args lists the names and types of any additional parameters, and R 
is the result type. In this paper, all parameters are in-parameters. In addition to 
declaring the name and signature of the method, the declaration associates with it 
as a specification the precondition P , postcondition Q , and modifies list w . A 
program can contain at most one declaration for a given method for a given type; 
for example, we don't allow strengthening a method specification in a subtype 
(this is a simplification that does not actually limit expressiveness, see p. 348 
of [31]). In the postcondition, result denotes the result value, primed variables 
denote values in the post-state, and unprimed variables denote values in the pre- 
state. If the precondition or postcondition is omitted, it defaults to true ; if the 
modifies list is omitted, it defaults to the empty list. 

A method m for type T can be implemented differently for each subtype of 
T . A method implementation of m for some subtype U of T is declared by 

impl m(u: U, . . . args . . .): R is S end 
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where S is an executable statement, and the implementation signature 

(u: U, . . . args . . .).R 

coincides with the declared signature except (possibly) for the type of the first 
parameter. Statement S must satisfy (that is, the verifier checks that it satisfies) 
the specification associated with the m method for T . The ideas in this paper 
don't depend on the particular executable statements allowed. The examples in 
this paper use Algol-like executable statements, whose meaning we hope will be 
clear to the reader. 

A method is called by 

t.m(. . . args . . .) 

where t is an object (the actual self parameter), m is a method name, and args is 
a list of any additional actual parameters. The static type of t is used in determin- 
ing the declaration and specification of m . The declaration is used to type-check 
the actual parameters and determine the static type of the result, the specification 
is used to reason about the semantics of the call. The dynamic type of t is used 
at run-time to determine which implementation of m to invoke. Since all method 
implementations are proved to meet their specifications, and since the dynamic 
type of t is a subtype of the static type of t , it is sound to reason about the se- 
mantics of the dynamic dispatch in this way. 

Abstraction. A data field can be declared to be abstract by preceding its decla- 
ration with spec . For example: 

spec var valid: T -> bool 

An abstract field occupies no memory at run-time; it is a fictitious field whose 
value (or representation) is defined as a function of other fields. The representa- 
tion is declared by a syntax like 

rep valid[t: T] = f[t] # 0 (0) 

which means that for any object t of type T , the abstract value of valid[t] is true 
if and only if f[t] # 0 . 

The representation of an abstract variable can be different for different sub- 
types. As an example, consider the object type Rat representing rational num- 
bers, and two of its subtypes, Ratio , which represents each rational as a ratio, 
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type Rat 

spec var valid: Rat -> bool 
type Ratio <: Rat 
var ««m, den: Ratio —> int 
rep valid[r: Ratio] = den[r] > 0 
type CFrac <: i?a? 
var parquo: CFrac -> array[int] 
rep valid[cf: CFrac] = 
parquo[cf] ^ nil A 

(V/ :: 1 < / < number (parquo[cf]) =>■ parquo[cf][i] > 0 } 

Figure 0: An example program, illustrating that representation of an abstract vari- 
able can be subtype-specific. 

and CFrac , which represents each rational as a continued fraction (which is a 
representation of a rational as a sequence of integers), see Figure 0. These dec- 
larations specify that the concrete representation of valid[q] varies depending on 
the dynamic type of q : for rationals represented as ratios, validity means that the 
denominator is positive, whereas for continued fractions, validity means that each 
partial quotient is positive, except possibly the first. 

A rep declaration given for a type T applies to all non- nil objects of type 
T , including those whose dynamic type is a subtype of T . One might think 
that it would be possible to override a rep declaration for T with another rep 
declaration for some subtype of T , but this is not allowed. This rule is enforced 
at link-time. 

The variables appearing in the right-hand side of the rep declaration for an 
abstract variable are called dependencies of the abstract variable. The dependen- 
cies can themselves be either concrete or abstract. Our notion of dependencies is 
not to be confused with use-def dependencies [2]. 

A major novelty of our approach is to require that dependencies be declared 
explicitly. For example, the representation (0) would cause an "undeclared de- 
pendency" error unless /[/] were declared as a dependency of valid[t] , which is 
done by a declaration of the form 

depends valid[t: T] on f[t] 
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In this paper, we sometimes omit the ":T" when T is obvious or unimportant. 
The depends declaration can be subtype-specific, just like the rep declaration. 
For example, the representations in Figure 0 might be accompanied by 

depends valid[r. Ratio] on den[r] 

depends valid[cf: CFrac] on parquo[cf], elems[parquo[cf]] 

The validity of the continued fraction cf depends both on the array parquo[cf] 
and on the contents of the array. These are different dependencies and both must 
be declared, as shown above. The validity of the ratio r depends only on den[r] . 

This paper is principally concerned with two forms of dependencies, static and 
dynamic. A static dependency has the form 

depends a[t: T] on c[t] (1) 

A dynamic dependency has the form 

depends a[t: T] on c[b[t]] (2) 

In each case, a is an abstract variable and c is either an abstract or a concrete 
variable. In the case of the dynamic dependency, b is concrete. A dependency on 
the contents of an array counts as a dynamic dependency, with elems playing the 
role of c . Other forms of dependencies will be discussed in Section 9.1, but static 
and dynamic dependencies are more common and fundamental. 

A major goal of this paper is to design a discipline for the placement of depen- 
dency declarations in a multi-module program. The paper is long, but the main 
conclusion is short: the static dependency (1) must be visible wherever c is, and 
the dynamic dependency (2) must be visible wherever b is. 

Dependencies affect the verification process in several ways. One way is mod- 
ifies list desugaring. For example, in a scope where 

depends a[t] on c[t] 
is visible, the modifies list 

modifies a[t] 
is desugared into something like 

modifies a[t], c[t] 

This reflects the common-sense view that the license to modify an abstract vari- 
able implies the license to modify its representation. The precise details of modi- 
fies list desugaring will be described later in the paper. 
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4 Example: Readers 



From our experience with ESC, we have found that dependencies are not just a 
detail but a key ingredient of the specification language that we used constantly. 
However, since dependencies are a tool for programming in the large, no small 
example does them full justice. This section presents the smallest example we 
know that motivates the essential points: a simplified version of readers, which 
are the object-oriented buffered input streams used in the standard I/O library of 
Modula-3. A key point that the example will illustrate is that modern information 
hiding together with subtyping creates situations where both an abstract variable 
and one or more of its dependencies are visible, but the associated representation 
is not visible. In these situations, sound modular verification would be impossible, 
but dependencies save the day. 

Readers (and their output counterparts, writers) were invented by Stoy and 
Strachey for the OS6 operating system [47]. Although Stoy and Strachey never 
used the word "object" or "class" in describing them, they are in fact one of the 
most compelling examples of the engineering utility of object-oriented program- 
ming. Each reader is an object with a buffer and a method for refilling the buffer. 
Different subtypes of readers override the refill method with code appropriate to 
that type of reader; for example, a disk reader fills the buffer from the disk, a 
network reader from the network. 

As part of the ESC project, we have mechanically verified the absence of errors 
from most of the Modula-3 standard I/O library, including all the standard reader 
subtypes. In this paper we want to focus on generalized data abstraction, and 
many of the complexities of the actual I/O system would distract us from this 
focus, so we will simplify the reader interface rather drastically. (The actual code 
and specifications that we have used as input to the Extended Static Checker can 
be found on the Web [13].) 

Our simplified interface Rd declares the type T representing a reader, and 
specifies the two methods getChar and close , see Figure 1 . Since our examples 
show ESC verifications only, we specify the range type of state as any , and we 
ignore the effects on state in the ensures clauses. We use the convention that 
rd.getCharQ returns — 1 when rd is exhausted, and otherwise returns the next 
byte of input. The specification of close reflects the design decision that a reader 
can be closed only once (a second call to close requires validity, which may have 
been destroyed by the first call). 

Next we describe the unit that defines the generic buffer structure (by generic, 
we mean common to all readers, as opposed to subtype-specific), see Figure 2. 
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unit Rd 
typeT 

spec var valid: T -> bool 
spec var state: T -> any 
proc getChar(rd: T): int 

requires valid[rd] 

modifies state[rd] 

ensures — 1 < result < 256 
proc close(rd: T) 

requires valid[rd] 

modifies valid[rd], state[rd] 

Figure 1: The interface Rd , which declares type T representing readers. 

The integer cur[rd] is the index in the abstract stream rd of the next byte to be 
returned by getChar . The integers lo[rd] and hi[rd] delimit the range of bytes 
in the abstract stream that are contained in the buffer buff[rd] (see Figure 3). 

Interface RdRep declares and specifies the refill method, but leaves its im- 
plementation to various subtypes. The convention used by refill is that the call 
rd.refillQ must make at least one new byte available (that is, it must establish 
cur[rd] < hi[rd] ), unless rd is exhausted, in which case it must establish the 
condition cur[rd] = hi[rd] . 

The postconditions of getChar and refill don't reflect the conventions for 
signaling that the reader is exhausted (nor does the variable state describe the 
condition that the reader is exhausted), because our example is an ESC verifica- 
tion, not a verification of full functional correctness. 

The rep declaration reveals the representation of the abstract variable valid 
in terms of the concrete variables lo , cur , hi , and buff . In addition, because 
subtypes may have their own validity invariants, the interface declares the ab- 
stract variable svalid , and adds the conjunct svalid[rd] to the representation of 
valid[rd] . The intended meaning of svalid[rd] is that rd satisfies the validity in- 
variant of its dynamic type. Each subtype of Rd.T will include a rep declaration 
specifying the representation of svalid for readers of that subtype. For example, a 
reader for a disk file would include a file handle as one of its fields, and its svalid 
would include the validity of the file handle. 
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unit RdRep import Rd 
var lo, cur, hi: Rd.T -> int 
var buff: Rd.T -> array[byte] 
spec var svalid: Rd.T -> bool 
rep valid[rd: Rd.T] = 
re? ^ nil A 

0 < lo[rd] < cur[rd] < hi[rd] A 

buff[rd] ^ nil A hi[rd] — lo[rd] < number (buff[r d]) A 

svalid[rd] 
proc refilled: Rd.T) 

requires valid[rd] 

modifies state[rd] 

ensures cur[rd] = cu^lrd] 
depends valid[rd:Rd.T] on lo[rd], cur[rd], hi[rd], buff[rd], svalid[rd] 
depends state[rd:Rd.T] on lo[rd], cur[rd], hi[rd], buff[rd], 

elems[buff[rd]] 
depends svalid[rd: Rd.T] on lo[rd], hi[rd], buff[rd] 

Figure 2: The interface RdRep , which defines the buffer structure common to all 
objects of type Rd.T . 



lo[rd] 



cur[rd] 



hi[rd] 



Abstract 
Source 



buff[rd] 



Figure 3: Buffer representation of readers. 
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unit Rdlmpl import Rd, RdRep 
impl getCharird: Rd.T): int is 

if cur[rd] = hi[rd] then rd.refillQ end ; 
if cur[rd] = hi[rd] then 

result := — 1 
else 

result := buff[rd][cur[rd] — lo[rd]] ; 
cur[rd] := cur[rd] + 1 
end 
end 

Figure 4: The implementation unit Rdlmpl , which contains the implementation 
of the method getChar . 

The depends declaration for valid is explained by our requirement that de- 
pendencies be explicit — without it, the checker would complain that the rep dec- 
laration for valid contains undeclared dependencies. The depends declarations 
for state and svalid are more subtle and will be explained later. 

Next we present the generic implementation in Figure 4. 

To give the flavor of an ESC verification, consider checking that cur[rd] — 
lo[rd] is a valid index into buff[rd] in the implementation of getChar . Since 
valid[rd] is a precondition of getChar , and is preserved by rd.refillQ , we con- 
clude that valid[rd] holds at the first semicolon. Thus, the validity of the index 
boils down to showing that 

0 < cur[rd] — lo[rd] A cur[rd] — lo[rd] < number (buff[rd]) (3) 

follows from 

valid[rd] A cur[rd] hi[rd] (4) 

Since Rdlmpl imports RdRep , the representation of valid[rd] is visible. Since 
this representation contains the conjunct lo[rd] < cur[rd] , the first conjunct of 
(3) follows immediately. The proof of the second conjunct is: 

cur[rd] — lo[rd] 

< { cur[rd] < hi[rd] A cur[rd] ^ hi[rd] (from (4)) } 
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unit BlankRd import Rd 
type T <: Rd.T 
proc init(brd: T, n:'mt):T 
requires 0 < n 

modifies valid[brd], state[brd] 
ensures valid' [brd] A result = brd 

Figure 5: Unit BlankRd declares a subtype BlankRd.T of Rd.T , whose readers 
deliver streams of blanks. 

hi[rd] — lo[rd] 
< { valid[rd] } 

number (buff[rd]) 

Returning to general comments about rd.getCharQ , notice that the imple- 
mentation modifies cur[rd] , but the modifies clause in the specification of the 
method getChar does not mention cur[rd] . Why does the checker not com- 
plain? Because of modifies list desugaring, as mentioned in the previous section. 
Modifies list desugaring gives getChar the license to modify cur[rd] , because 
getChar is specified to modify state[rd] , which is declared in RdRep to depend 
on cur[rd] . This explains why cur[rd] was declared a dependency of state[rd] . 

The object-oriented I/O stream design by Stoy and Strachey illustrates the flex- 
ibility of subtyping: having carefully designed the central abstraction Rd.T , it can 
serve as the blueprint for dozens of useful subtypes. To illustrate the modularity 
issues that arise when a subtype is defined, we now give the interface (Figure 5) 
and implementation (6) of a trivial type of reader, a blank reader, which delivers 
a sequence of blanks whose length is determined at initialization time. More pre- 
cisely, the expression new {BlankRd. T).init{n) allocates, initializes, and returns a 
reader that delivers a stream of exactly n blanks. The conjunction "result = brd" 
in the postcondition specifies that the init method return the object that it initial- 
izes, a convention we have found useful. The method init stores the argument n 
in the field num[brd] for later use by the method refill . The method also initial- 
izes the lo , cur , and hi fields in the obvious way, allocates a buffer of size up to 
8192 (that is, up to 8 kilobytes), and fills the buffer with blanks (code 32). 

As we shall see later, it is critical to the verification of the module that each 
blank reader brd satisfy the invariant hi[brd] < num[brd] . Therefore, the unit 
BlankRdlmpl provides a subtype- specific representation for svalid , effectively 
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unit BlankRdlmpl import Rd, RdRep, BlankRd 
var num.: BlankRd.T —> int 

rep svalid[brd: BlankRd.T] = hi[brd] < num[brd] 
impl init{brd: BlankRd.T, n: int): BlankRd.T is 
num[brd] := n ; 

buff[brd] := new(byte, min(8192, n)) ; 
lo[brd] := 0 ; cur[brd] := 0 ; 
hi[brd] := number (buff[br d]) ; 
for ?' := 0 to hi[brd] — 1 do 

buff[brd][i] := 32 
end ; 

result := Z?rd 
end 

impl refill(brd: BlankRd.T) is 
lo[brd] := cwr[£r<i] ; 

hi[brd] := min(/o[^rJ] + number (buff[brd]), num[brd]) 
end 

depends state[brd: BlankRd.T] on num[brd] 
depends svalid[brd: BlankRd.T] on num[brd] 

Figure 6: The blank reader implementation unit BlankRdlmpl . 
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strengthening the general reader validity invariant as needed for the particular 
subtype BlankRd.T . 

Notice that brd.refillQ must be proved to maintain valid[brd] , because its 
modifies list does not allow it to modify valid[brd] . Among the proof obligations 
associated with maintaining valid[brd] is that at exit, 

cur'[brd] < hi'[brd] 

Since the body of refill does not change cur[brd] and makes hi'[brd] equal to 

min(cur[brd] + number (buff [brd]) , num[brd]) 

proving this postcondition boils down to showing that each argument to min is at 
least cur[brd] . For the first argument, this follows from the fact that the number 
of any array is non-negative. The proof for the second argument is: 

valid[brd] 
=>• { rep for valid } 

cur[brd] < hi[brd] A svalid[brd] 
= { brd is of type BlankRd.T, rep for svalid for this type } 

cur[brd] < hi[brd] A hi[brd] < num[brd] 
=>■ { transitivity } 

cur[brd] < num[brd] 

We present this calculation in detail to illustrate that the verification of the refill 
method of even the trivial BlankRd.T requires the subtype-specific validity con- 
junct. (The need for the svalid conjunct is more conspicuous in more interesting 
reader subtypes.) 

Read-only by specification. The calculation that cur[brd] < num[brd] follows 
from valid[brd] would be in vain if the generic code could modify hi[brd] . If, 
for example, the generic implementation of rd.getCharQ would sometimes in- 
crement hi[rd] , then it could destroy svalid[rd] , which could cause all kinds of 
errors. To prevent this, the Modula-3 interface from which we translated RdRep 
contains the following English comment: 

The generic code modifies cur[rd], but not lo[rd], hi[rd], or buff[rd]. (5) 

This guarantee is essential to subtypes, since between calls to their refill methods, 
they may need to know that lo , hi , and buff have not been changed by the 
generic code. 
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How do we translate the sentence (5) into a formal specification? Modula-3 
does not have any kind of readonly qualifier for field declarations. Java and C++ 
have qualifiers like private and protected, but these declarations don't help 
with the current problem. Both of them allow the implementation to read and write 
the fields, while limiting the access from subtypes (and from other clients). What 
we need here is almost the opposite: a declaration that will forbid the generic 
implementation from writing the fields, while allowing subtypes to write them. 
We can hardly expect a programming language to have a declaration qualifier that 
enforces this highly particular access policy, but modular verification will not be 
sound unless the access policy is formally stated and enforced. 

We wrestled with the problem for some time before realizing happily that 
depends provides a neat solution. In fact, the third dependency declaration in 
RdRep , which states that svalid[rd] depends on lo[rd] , hi[rd] , and buff[rd] , is 
the desired formalization of (5). For if the generic code were to modify any of 
these fields, the presence of the dependency would alert the checker to the pos- 
sibility that svalid, and therefore valid, might be changed. In other words, in 
a scope where lo[rd] , hi[rd] , and buff[rd] are known to be part of the repre- 
sentation of svalid[rd] , but the explicit representation is unknown, the only hope 
for maintaining svalid[rd] invariant is to avoid modifying lo[rd] , hi[rd] , and 
buff[rd] . We call this technique "read-only by specification". 

Summary. To repeat our main conclusion from this example, we see that mod- 
ular verification with subtyping creates situations where both an abstract variable 
and one or more of its dependencies are visible, but where the associated repre- 
sentation is not visible. We have seen two instances of this: 

• The dependencies of state are specified in RdRep , but no representation for 
state is specified. The dependencies must be visible so that the implemen- 
tations of operations that modify the state (for example, getChar ) will have 
the license to modify the concrete variables that represent the state. The 
representation declaration cannot be visible, for two reasons. First, because 
we are doing extended static checking only, we never give a representation 
for the state. Second, even if we were doing full-scale verification, the rep- 
resentation would be subtype-specific, but the dependencies must be visible 
in the generic scope. 

• The dependencies of svalid are specified in RdRep , but no representation 
for svalid is given there. The dependencies are necessary to prevent generic 
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operations from modifying the variables that are reserved for the use of 
subtypes. But it is clearly impossible to present a representation declaration 
for svalid in the RdRep scope, since the whole point of svalid is to allow 
subtypes to include their own invariants as part of validity: these invariants 
can't be known in the generic scope. 

Explicit dependencies may seem verbose, and it would be nice to be able to 
infer them automatically. But this will not always be possible. For example, of the 
three depends declarations in RdRep , we can imagine inferring the first (from 
the rep declaration for valid ), but the second and third could not be automatically 
inferred since they are used to specify non-trivial design decisions (namely, which 
fields can be modified by generic code, and which can be modified by subtypes 
only). 

This concludes our example of the role of dependencies in modular verifica- 
tion. In the remainder of the paper, we investigate different kinds of dependencies 
and the way they affect the verification process. 

5 Static dependencies 

In this section, we describe more fully how dependencies affect the verification 
process. Our guiding principles are: 

• Abstract function principle. An abstract variable is a function of the con- 
crete variables on which it depends. 

• Abstraction modification principle. The license to modify an abstract vari- 
able implies the license to modify its concrete representation, but the license 
to modify a concrete variable does not imply the license to modify an ab- 
stract variable that depends on it. 

Our technique is to rewrite preconditions, postconditions, modifies lists, and rep 
declarations into equivalent forms that contain concrete variables only. In this 
section, we will describe the rewriting steps and explain how they follow from the 
principles. 

We confine ourselves to static dependencies for simplicity; in Section 7, we 
will extend this material to dynamic dependencies. 
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5.0 Functionalization 



Guided by the abstraction function principle, and following in the footsteps of 
Hoare, we introduce a new function symbol for each abstract variable. In this 
paper, we write T.a to denote the function symbol introduced for the abstract 
variable a . The idea is that T.a gives a 's value as a function of the concrete state. 
Occurrences of a in preconditions and postconditions are replaced by function 
applications of the form T.a(. . .) . For example, a[t] > 6 becomes T.a(. . .)[t] > 
6 . The arguments to T.a are the variables on which a depends (together with 
other arguments that will be introduced later). The process of substituting T.a for 
a is called functionalization. 

The rep declaration for a is rewritten into an appropriate axiom about T.a 
(a rep axiom). If a is visible but its representation is not, then T.a occurs in the 
rewritten program but its rep axiom does not. In this case, the theorem prover 
treats T.a as an uninterpreted function. 

Functionalization and pointwise axioms. There are more details to be pre- 
sented about functionalization. We will introduce them with an example. Con- 
sider 

spec var a: T -> X 
var c: T -> Y 

, ^ 7 (6) 
var d:T —> Z 

depends a[t: T] on c[t], d[t] 

Then occurrences of a are replaced by the expression T.a(c, d) . Had c for exam- 
ple also been abstract, functionalization would continue, producing the expression 
T.a(T.c(. . .), d) . 

Notice that c , d , and T.a(c, d) are all maps. In typical functionalized expres- 
sions, we can expect to encounter expressions like T.a{c, d)[t] . Allowing T.a to 
take maps as arguments is technically convenient, but without further restrictions, 
it would allow T.a(c, d)[t] to depend on the entire maps c and d , which we 
do not want: our view is that the dependency declaration 6) implies that a[t] is 
unchanged by a modification to c[s] or d[s] fors^t. We enforce this point of 
view by imposing a pointwise axiom on each abstraction function. In the case of 
a , c , and d above, this axiom is: 

(Vt.T, cO, cl, JO, dl :: 

c0[t] = cl[t] A d0[t] = dl[t] (7) 
=>• T.a(cO, d0)[t] = T.a(cl, dl)[t] ) 
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We would like to emphasize that in (7), variables cO , cl , dO , and d\ are dum- 
mies, not program variables. Even if program variables c and d were abstract, 
there would be no need to functionalize the dummies in (7). 

For each abstract variable, there will be a pointwise axiom for each subtype 
of its index type, since different subtypes may have different dependencies. For 
example, consider 

typeT 

spec var a:T -> X 
type U < : T 
var r.U^Y 
depends a[u: U] on c[u] 
type V <: T 
var d:V -> Z 
depends a[v: V] on d[v] 

There will be three pointwise axioms, one for each of the types T , U , and V . 
The axiom for T is (7), the same as the axiom where c and d had index type T . 
The axiom for U is 

(V«: C/, cO, cl, JO, Jl :: 
cO[w] = c1[m] 

=> J:a(c0, J0)M = F.a{c\, dl)[u] ) 

The axiom for V is similar. 

When rewriting a postcondition, a post- value a' leads to post- values in the ar- 
guments to T.a . For example, the postcondition of init for blank readers includes 
the conjunct 

valid' [brd] 

This is rewritten into 

J r .valid(lo' , cur' , hi', buff', T.svalid{rd, lo' , hi' , buff'))[rd] 

The number of arguments of T.a depends on the number of dependencies of 
a that are visible in the scope where the rewriting takes place. For example, in the 
unit RdRep , T.svalid has four arguments, whereas in BlankRdlmpl, T.svalid 
has five arguments because of the extra dependency of svalid[brd] on num[brd] . 
Within the verification of any one unit, all occurrences of T.a have the same 
number of arguments. 
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Rep axioms. We now explain how a rep declaration is rewritten into a rep 
axiom. A rep declaration has the form 

rep a[t: T] = R 

where the only free variables allowed in R are fields that are dependencies of 
a , and each occurrence of such a field must be indexed by the dummy t . For 
definitiveness, suppose that these dependencies are 

var c.T X 
var d:T -> Y 

depends a[t: T] on c[t], d[t] 

This rep declaration is rewritten into the rep axiom 

(Vf.T, cV, dV :: T.a{cV, dV)[t] = R(c, d := cV, dV) } 

in which we use the assignment operator to denote substitution. In this axiom, 
we have appended V s in the names of the dummies to emphasize that they are 
universally quantified dummies, not the program variables c and d . 

The same treatment works with minor alterations to accommodate subtype- 
specific rep declarations and dependencies. For example, the rep declarations 
in 

typeT 

spec var a: T -> W 
var c: T -> X 
depends a[t: T] on c[t] 

type TO < :T 
var d: TO -> Y 
depends a[t: TO] on d[t] 
rep a[t: TO] = RO 

type T\ <: T 
var e: Tl -> Z 
depends a[t: Tl] on e[t] 
rep a[t: Tl] = Rl 
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produce the rep axioms 



(Vt.TO, cV, dV, eV :: T.aicW , dV, eV)[t] = R0(c, d := cV, dV) ) 
(Vt.Tl, cV, dV, eV :: F.a{cV, dV, eV)[t\ = Rl(c, e := cV, eV) ) 

Note that different rep axioms are produced for the different rep declarations. 
Note also that all dependencies of a for any subtype become arguments to F.a , 
and each axiom ignores those arguments that are irrelevant to its subtype. 

Examples. In the unit RdRep described previously, the precondition of refill is 
written 

valid[rd] 

Using the static dependencies of valid[rd] , this precondition is rewritten into 

T.valid{lo, cur, hi, buff, svalid)[rd] 
Since svalid is itself abstract, the rewriting continues: 

J r .valid(lo, cur, hi, buff, J-'.svalidilo, hi, buff))[rd] (8) 

which is the final functionalized form of valid[rd] in the scope RdRep . 

As an example of a rep axiom, the rep for valid in RdRep is rewritten into 

{Vrd:Rd.T, loV, curV, hiV, buffV, svalidV :: 
T.validiloV ' , curV, hiV, buffV , svalidV)[rd] = 
rd j£ nil A 

0 < loV[rd] < curV[rd] < hiV[rd] A (9) 
buffV[rd] # nil A 

hiV[rd] - loV[rd] < number (buffV[rd]) A 
svalidV[rd] ) 

To see how these formulas work together, consider the verification of the 
method refill . The rewritten precondition (8) together with the rep axiom (9) 
allow the verifier to conclude that buff[rd] ^ nil , by instantiating buffV to buff , 
loV to lo , and so on. 

Because RdRep contains no rep declaration for svalid , T.svalid remains an 
uninterpreted function in this scope. A subtype-specific rep axiom is produced in 
the scope of an implementation of a reader subtype like BlankRd . 
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(In this description, we have glossed over some detailed rules that prevent 
representations for different subtypes from producing inconsistent values of an 
abstract variable at nil .) 

Our final example illustrates reasoning about the abstraction function as an 
uninterpreted function symbol. Consider the following generic procedure, which 
replaces a reader's buffer, copying the contents of the old buffer into the new: 

proc copyBuffer(rd: Rd.T) 
requires valid[rd] 
modifies state[rd] 
impl copyBuffer(rd: Rd.T) is 

var nb := new (byte, number (buff[rd])) in 
for i := 0 to number (buff[r d]) — 1 do 

nb[i\ := buff[rdm 
end ; 

buff[rd] := nb 
end 
end 

The proof that copyBuffer maintains valid[rd] boils down to proving 

lo[rd] = lo'[rd] A hi[rd] = hi'[rd] A elems[buff[rd]] = elems'[buff'[rd]] 

svalid[rd] = svalid'[rd] 
which functionalizes into 

lo[rd] = lo'[rd] A hi[rd] = hi'[rd] A elems[buff[rd]] = elems'[buff'[rd]] 

T.svalid{lo, hi, buff)[rd] = T.svalid{lo' ' , hi', buff')[rd] 

But this cannot be proved, since distinct arrays may have the same elements. Thus, 
the checker would reject copyBuffer , warning that it possibly destroys the validity 
of rd . This warning is accurate, since generic code is not allowed to modify buff . 
For example, the design of readers allows a subtype to cache the buffer pointer, but 
such a cache would be invalidated unexpectedly by copyBuffer . Thus, reasoning 
about the abstraction function as an uninterpreted function symbol enforces the 
read-only by specification idiom. 
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An alternative design for readers would have replaced the dependency 
depends svali d[rd] on buff[rd] 

by 

depends svalid[rd] on elems[buff[rd]] 

In this design, copyBuffer would be legal, and it would be illegal for subtypes to 
assume that the buffer pointer remains unchanged by generic code. This happens 
not to be the approach taken by the Modula-3 I/O library. 

So much for rewriting preconditions and postconditions. Now we consider 
rewriting modifies lists. 

5.1 Modifies list desugaring 

Guided by the abstraction modification principle (page 19), we introduce a closure 
operation on modifies lists. The closure operation expands the modifies list as 
required by the first half of the principle without expanding it so much as to violate 
the second half of the principle. The rewritten specification allows a method to 
modify a field f[s] (abstract or concrete) if and only if the closure of the method's 
modifies list includes f[s] . Thus the rewriting is parameterized by the definition 
of closure. In this section, we first define the rewriting from a closed modifies 
list, and then define the closure operation appropriate for static dependencies. In 
Section 7.1, we will define the closure operation for dynamic dependencies. 

Modification constraints. Closed modifies lists are rewritten into modification 
constraints. Consider a specification 

modifies M ensures P (10) 

occurring in a scope D . We rewrite this specification into 

modifies N ensures P A Q 

where N is the list of all concrete maps / for which a term of the form f[E] 
occurs in the closure of M , and Q is a conjunction with one conjunct for each 
map variable visible in the scope. The conjunct for a particular map / asserts that 
f[s] changes only where it is allowed to change. That is, if {/[2s i], . . . ,/[2s„] } is 
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the set of terms in the closure of M of the form /[. . .] (that is, the set of terms 
whose outer map variable is /), then the conjunct for / is 

(Vs :: m=f[s] v s = E x V ... v s = E n ) 

We call this conjunct the modification constraint for / , and we call {E\, . . . , E n } 
the set of modification points of / . The modification constraint for a map variable 
limits the points at which the variable may be modified, that is, it protects the 
variable from change at other points. In particular, if the dependencies of an 
abstract variable a are changing at points where a itself is not allowed to be 
changed, a 's modification constraint limits the modification of a 's representation 
to preserve the values at points where a is not allowed to change. We say that a 
is protected from changes to its representation. 

(When verifying an implementation, ESC does not bother to produce a modi- 
fication constraint for a map if a syntactic scan of the implementation determines 
that the map is never changed by the implementation.) 

This strengthening of the postcondition occurs before the postcondition is 
functionalized. 

Closure definition. A set of terms M is statically closed in a scope D if 

a[E] g M A "depends a[t] on c[?]" eD => c[E] g M 

(We have intentionally ignored the type of E and the index types of a and c in 
this definition. Thus, a closed set of terms may include f[E] even if E is not of 
the index type of / . Actually, ESC does use type information to produce a smaller 
closure, but in retrospect, we don't think it makes much difference.) 

The static closure of a modifies list is its smallest statically closed superset. 

For example, in the scope of the unit BlankRdlmpl, the static closure of 
valid[brd] is 

lo[brd], cur[brd], hi[brd], buff[brd], svalid[brd], num[brd] 

Example. As an artificial example, suppose that / is a concrete field and con- 
sider the dependencies 

depends g[t] on f[t] 
depends h[t] on f[t] 
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and the modifies list 

modifies g[u], f[v] 
The static closure of this modifies list is 

modifies g[u],f[u],f[v] 
This produces the rewritten specification 

modifies/ 

ensures ( Vs :: g[s] = g'[s] v s = u } A 

(Vs :: f[s] =f[s] v s = u v s = v } A 
(Vs :: Mj] = fc'M > 

Notice that since there are no modification points for h , the conjunct for h in 
the rewritten postcondition does not allow it to be changed anywhere. Thus, the 
second half of the abstraction modification principle is satisfied: the license to 
modify g[u] does not imply the license to modify h[u] , even though g[u] and 
h[u] have the concrete dependency f[u] in common. Also, the license to modify 
f[v] does not imply the license to modify g[v] or h[v] . 
Finally, functionalization produces 

modifies/ 

ensures ( Vs :: f.g(f)[s] = T.g(f')[s\ v s = u } A 

(Vj :: f[s] =f[s] v s = u v s = v } A 

(Vs :: T.h(fm = F.h(f')[s\) 

That is, the specification allows changes to / at indices u and v , provided the 
changes preserve the value of F.hif)^] for all s, and F.gif)^] for all s except 
u . 

6 Soundness of modular verification 

We remind the reader that we are interested in modular soundness, that is, the 
property that the separate verifications of the individual modules of the program 
suffice to ensure the correctness of the composite program. 

The standard approach for reasoning about procedure calls breaks down for 
modular programs. The standard approach reasons about a procedure call by as- 
suming that it meets its specification, and discharges this assumption by verifying 
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the implementation of the procedure. The approach breaks down if the specifi- 
cation is interpreted differently in the two contexts. But as we have seen, the 
meaning of a modifies list depends on the scope in which it is used. In particular, 
it may be desugared differently when reasoning about a call to a procedure than 
when reasoning about the implementation of the procedure. 

To be more precise about modular soundness, we will define scope mono- 
tonicity, which means that anything verifiable in a scope is also verifiable in any 
larger scope. Then, we will argue that modular soundness is equivalent to scope 
monotonicity. The notion of scope monotonicity seems to be new. 

For a scope D and a procedure implementation P in D , the judgment 

D h P 

means that P meets its specification in D . More precisely, let 

requires Pre modifies M ensures Post (11) 

be the result of desugaring the specification of P in scope D , as described in 
Section 5. Let A be the body of P , and let R be the conjunction of pointwise ax- 
ioms and rep axioms in D , as described in Section 5.0. The requirement is that R 
implies that A meets the specification (11). In checking this, the verification con- 
dition generator reasons about method calls within A by using their specifications 
as desugared in D . 

We say that h is monotonic with respect to scope if, for any procedure imple- 
mentation P and scopes D and E , 

if D c E , then D h P implies E \- P 

If we can prove that h is monotonic with respect to scope, then it is reasonable 
to say that our modular verification system is sound. For, if P has been verified 
in a scope D , that is, if we have proved D h P , it follows by monotonicity that 
E h P , where E is the entire program. Thus, anything that verifies in a limited 
scope would also verify had there been no information hiding and all information 
had been global. 

It is too much to hope that h be monotonic in any program whatsoever. We 
will impose some requirements, called modularity requirements, such that h is 
monotonic in any program that meets the requirements. We will also argue that 
these requirements are reasonable from a methodological point of view, that is, 
that they don't rule out useful designs. 
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Our notion of modular soundness is different from the soundness of an ax- 
iomatic semantics with respect to an operational semantics. The consistency of 
axiomatic and operational semantics is certainly important, but it concerns the 
conventional control structures of programming in the small, like iteration and 
conditionals. These are mostly irrelevant to the issues of information hiding in 
programming in the large, which are the issues of concern in this paper. In this 
paper, we simply assume that the standard operational semantics is consistent with 
the axiomatic semantics of a single-module program. Therefore, any discrepancy 
between the axiomatic and operational semantics is due to unsound modular ver- 
ification. 

6.0 Visibility requirement 

Our first modularity requirement is the visibility requirement. A program satisfies 
the visibility requirement if each of its static dependencies 

depends a[t] on c[t] 

is visible in every scope in which both a and c are visible. 

It is easy to see that this requirement is necessary to have any hope of achieving 
scope monotonicity. Suppose there were a scope where a and c were visible 
but the dependency is not. In such a scope, it is provable that a change to c 
has no effect on a . But this would not be provable in a larger scope where the 
dependency is visible. 

The requirement is necessary for informal as well as formal checking. If a 
program violated the requirement, it would be impossible to reason about a and 
c in the scope where they are visible but the dependency is not. In such a scope, 
an assignment to c could change a unexpectedly, and a call to a procedure that 
modifies a could change c unexpectedly. Nothing in the program text warns 
of either side effect. Almost all failures of scope monotonicity can be traced to 
unexpected side effects of this sort. 

For example, consider what would happen if the dependency 

depends svalid[rd] on hi[rd] 

were placed not in unit RdRep but in unit BlankRdlmpl . A modular checker 
would then allow the generic implementation, where the dependency of svalid 
on hi is not visible, to increase the value of hi[rd] beyond num[rd] , which for 
blank readers destroys validity. 
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6.1 Top-down requirement 



The second modularity requirement is the top-down requirement. A program sat- 
isfies the top-down requirement if, for each of its static dependencies 

depends a[t] on c[t] 

variable a is visible in every scope in which c is visible. 

Here's an example of a rather pathological program unit that violates the top- 
down requirement. 

unit U import R d, RdRep 
type T <: Rd.T 
spec var isEven: T -> bool 
depends isEven[t: T] on cur[t] 
rep isEven[t: T] = cur[t]mod2 = 0 
proc P{t: T) 

requires Rd.valid[t], isEven[t] 

modifies Rd.state[t] 
impl P(t: T) is 

t.getCharQ ; assert cur[t] mod 2 = 0 

end 

This pathological unit would verify, since 

• the precondition of P requires isEven[t] , 

• isEven[t] does not appear in the modifies list of getChar , and consequently, 
isEven[t] is formally provable at the exit of the call to t.getChar( ) , and 

• the representation of isEven[t] implies cur[t] mod 2 = 0 . 

But of course the assert would fail at run-time, since getChar will change the 
parity of cur[t] . 

At first, this problem may not seem like a failure of scope monotonicity, but 
it is. The getChar method verified in the scope Rdlmpl, where it was presented 
earlier in the paper. But if the scope Rdlmpl were expanded by importing the unit 
U , then getChar would no longer verify, because it does not preserve the value 
of isEven[t] . 
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To put it another way, the problem is that isEven is not visible in the scope 
where getChar is implemented, and therefore the desugaring of getChar 's spec- 
ification does not strengthen the postcondition to protect isEven from change. 
The top-down requirement ensures that isEven is visible wherever cur is, and 
thus any procedure that modifies cur and claims not to modify isEven will be 
checked appropriately. 

Here is an explanation of the name of this requirement. The reader package 
was designed in a top-down fashion, and cur was introduced as part of the con- 
crete representation of Rd. state and Rd.valid . To come along later and define a 
new unit ( U ) that attempts to use cur for part of the representation of something 
else ( isEven ) would be a violation of top-down design. We believe that imposing 
the top-down requirement for static dependencies does not rule out any useful de- 
signs. As we shall see in Section 7, the situation is more interesting for dynamic 
dependencies. 

6.2 Static placement rule 

There is a simple discipline that guarantees that both the visibility and top-down 
requirements are satisfied, called the static placement rule: simply place each 
static dependency 

depends a[t] on c[t] 

in the unit that declares c . We leave it to the reader to show that the visibility and 
top-down requirements follow from this rule. Furthermore, the converse is almost 
true: for programs without cyclic imports, if both requirements are satisfied, then 
the static placement rule is satisfied as well. Thus, if we'd like, we can replace both 
requirements by the rule. We have stated the requirements separately, because they 
seem to be separable concerns, and are used in different parts of the soundness 
proof. 

6.3 Residues 

The visibility and top-down requirements are two giant steps toward modular 
soundness. But they don't quite reach the goal. If they did, then the following 
implication would be true, for any procedure implementation P and scopes D 
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and E containing static dependencies only: 

D\- P and D c E and E satisfies the two modularity requirements 



Unfortunately, this is false according to the way of functionalizing abstract vari- 
ables described in Section 5.0. There is one more technicality that must be in- 
troduced to fix the problem, called residues. Here is an artificial program that 
demonstrates the problem: 



spec var a:T -> any 
var c.T -> int 
depends a[t: T] on c[t] 
proc outerQt: T) 

proc innerQ: T) modifies a[t] ensures c[t] = c'[t] 
impl outer(t: T) is t.innerQ end 

The absence of a modifies list for outer means that a call to outer has no side 
effects. We will now argue that without residues, unit A verifies. We then argue 
that it should not verify. Finally, we will define residues and explain how they fix 
the problem. 

As described in Section 5, the modifies list a[t] of the call t.innerQ has the 
static closure a\t\, c[t] , so the rewritten specification of t.innerQ) (before func- 
tionalization) is 

modifies c 

ensures c[t] = c'[t] A 



Eh P 



unit A 
typeT 



(Vs 
(Vs 



c[s] = c'[s] V S = t > A 
a[s] = a'[s] v s = t) 



After functionalization, the specification is 



modifies c 

ensures c[t] = c'[t] A 

( Vs :: c[s] = c'[s] v s = t ) A 

(Vs :: F.a(c)[s] = JRa(c')M v s = t) 
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The first two lines imply that c[s] does not change for any s . The third line then 
implies that a [s] , that is, !F.a{c)[s\ , also does not change for any s . Therefore, 
the call t.innerQ has no side effects at all, and the body of outer will verify. 

But we now argue that outer 's body should not verify. Consider the following 
unit B , providing an implementation of inner . 

unit B import A 

var d:A.T -> int 

depends a[t:A.T] on d[t] 

impl inner (t: A. T) is d[t] := 0 end 

Unit B reveals another dependency ( d ) of a , which the implementation of inner 
in fact modifies. Unit B will verify in isolation, because inner modifies only 
variables in the static closure of its modifies list a[t] . 

We are in trouble, because outer 's side effect on d will be unexpected in a 
scope that sees d together with outer 's specification: 

unit C import A, B 

proc R(t: A.T) modifies a[t] 
impl R(t:A.T) is 

var dd := d[t] in t. outer Q ; assert dd = d[t] end 
end 

This implementation verifies, because outer's modifies list does not include d , 
but clearly the assert will fail at run-time. 

This is a failure of scope monotonicity, because although outer 's body verifies 
in the unit A , it would not do so in the larger scope of unit B , where d is visible 
and the call t.innerQ will be desugared to have a side effect on d[t] . 

We blame the failure on the body of outer. Here's an informal explanation 
of why: Procedure outer , which is specified to be side-effect free, calls inner , 
which modifies a . Although a depends on c , it should not be inferred that 
a depends only on c . Therefore, the call to inner should be inconsistent with 
outer 's modifies list. 

Individual residues. To change our rewriting so that outer 's body will not ver- 
ify, we introduce residues. The residue of an abstract variable a , written res.a , 
can be viewed as a stand-in for those of a 's dependencies that are not visible. 
Residues are introduced automatically by the verifier and cannot be mentioned 
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explicitly in specifications or programs. The verifier treats every abstract variable 
declaration 

spec var a:T -> X 

as a shorthand for the three declarations 

spec var a:T —> X 
var res.a: T -> any 
depends a[t: T] on res.a[t] 

The implicit dependency of a on res.a introduces res.a into the static closure of 
any modifies list that mentions a , just as for explicit dependencies. 

Desugaring of modifies lists as described in Section 5 will now work out 
soundly for this example. The modifies list a[t] of the call t.innerQ in the body 
of outer has the static closure a[t], res.a[t], c[t] , so the rewritten specification of 
t.innerQ (before functionalization) is 

modifies c, res.a 
ensures c[t] = c'[t] A 

( Vs :: c[s] = c'[s] v s = t } A 

(Vs :: res.a[s] = res.a'[s] v s = t ) A 

( Vs :: a[s] = a'[s] v s = t) 

This allows both a[t] and res.a[t] to change, and therefore the implementation 
of outer will not verify. 

Shared residues. We are now very close to modular soundness, so close that it 
took our colleague Jim Saxe to find a sufficiently pathological example to demon- 
strate that we are not yet there. The example is shown in Figure 7. In this scope, 
the implementation of outer verifies, because a[t] and res.a[t] are allowed to be 
changed, c[t] is restored to its initial value, res.b[t] is not changed by the body, 
and the invariance of b[t] (i.e., of T.bires.b, c)[t] ) follows from the invariance 
of res.b and c . But in a larger scope in which it is revealed that a and b have a 
common dependency, outer will not verify: 

unit E import D 

vard.D.T -> int 
depends a[t: D.T] on d[t] 
depends b[t: D.T] on d[t] 



34 



unit D 

typeT 

spec var a.T -> int 
spec var b:T int 
var c: T -> int 
depends T] on c[t] 
proc outer (t: T) modifies a[t] 
proc inner (t: T) modifies a[t] 
impl outerit: T) is 

var cc := c|>] in 

c[t] := 0 ; t.innerQ ; c[f] := cc 

end 
end 



Figure 7: Example program that motivates shared residues. 

In scope E, the required proof of invariance of b[t] for outer does not go 
through. The modification constraint for b that is added to the postcondition 
of outer is 

(Vs :: F.b(res.b, c, d)[s] = T.bires.b, c, d)[s] } (12) 

where the accents on c and d denote their initial and final values. We do not 
accent res.b , because nothing in this example modifies it. The modification con- 
straints for b and d that we get to assume at exit from inner are 

(Vs :: d[s] = d[s] v s = t) A 

(Vs :: T.b{res.b, c, d)[s] = T.b{res.b, c, d)[s] ) 

where c denotes the value of c on entry and exit of inner , that is, 
c = store(c, t, 0) 

where the expression store(c, t, 0) denotes a map like c but mapping t to 0. 
Because d is unmodified except in the call to inner , d and d serve to denote 
the values of d around the call to inner as well as around the implementation of 
outer . 
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But (12) does not follow from (13). Although inner is constrained to modify 
d only in ways that preserve T.bires.b, c, d) , this constraint is in force only for 
the value of c at the time of the call to inner . Therefore, scope monotonicity and 
modular soundness do not hold. 

To restore modular soundness, we must arrange either that outer verifies in 
unit E or that it does not verify in unit D . We choose the latter, that is, we 
take the view that outer was misprogrammed: modifying part of the representa- 
tion ( c ) of an abstraction ( b ) whose representation is hidden and then calling a 
method ( inner) that may manipulate the abstraction is methodologically unjusti- 
fiable, even if the modification of c is restored after the call. 

Consider that the example might continue as follows: 

rep b[t: T] = c[t] ■ d[t] 
impl innerit: T) is 

if c[t] = 0 then d[t] := d[t] + 1 end 
end 

This possible continuation shows clearly that the failure of outer to verify in unit 
E is appropriate, and therefore its verification in unit D is inappropriate. 

The essential difficulty revealed by Saxe's example is that two abstract vari- 
ables that have no common dependency in a small scope may turn out to have 
a common dependency in a larger scope. To fix our proof system to be modu- 
larly sound, we will force all small-scope verifications to respect the possibility 
that larger scopes may reveal common dependencies. To do this, we introduce 
another residue variable, a shared residue sres to augment the individual residues 
introduced earlier. 

In more detail, sres is a predeclared variable visible in all scopes. The verifier 
treats every abstract variable declaration 

spec var a:T -> X 

as shorthand for 

spec var a:T -> X 
depends a[t: T] on sres[t] 
var res.a: T -> any 
depends a[t: T] on res.a[t] 

The combination of individual and shared residues achieves modular sound- 
ness. For Saxe's example, the attempted verification of outer in unit D will 
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now fail: the details of the failure are exactly the previously described details of 
the failure of outer to verify in unit E (see formulas (12) and (13)) with sres 
playing the role of d . 

It seems necessary to introduce both the shared residue and the individual 
residues. Here is an example that shows that the shared residue alone does not 
suffice for modular soundness. We begin with a small unit G : 

unit G 
typeT 

spec var a:T -> X 

spec var b:T -> Y 

proc outer (t: T) modifies a[t] 

proc inner(t: T) modifies b[t] ensures b[t] = b'[t] 

impl outerit: T) is t.innerQ end 

The following unit H shows that in a larger scope, the call to inner may have 
side effects that are not allowed by outer 's specification: 

unit H import G 

var c.T -> Z 
depends b[t: T] on c[t] 

But with the shared residue variable only, inner' s modification to the shared 
residue is consistent, in unit G, with outer's modification constraint. To achieve 
the verification failure that we need, we must distinguish res.a from res.b . 

6.4 Modular soundness for static dependencies 

The appendix contains a proof of modular soundness for programs whose depen- 
dencies are static, and that satisfy the visibility and top-down requirements, given 
that specifications are desugared as described in Section 5 and residues are used. 

This marks the end of our presentation of static dependencies. In the next 
section, we describe dynamic dependencies. 

7 Dynamic dependencies 

Most of the dependencies that arise in top-down program design are static. By 
a top-down design, we mean a design in which each successive layer of imple- 
mentation provides the representation of the abstraction specified in layers above. 
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However, not all useful designs are top-down. A bottom-up design is often bet- 
ter, in which an object type is defined and later used to build higher-level objects, 
which may not even have been envisioned at the time the first type was defined. 
Most of the dependencies that arise in bottom-up design are dynamic. 
Recall that a dynamic dependency has the form 

depends a[t] on c[b[t]] 

This means that the abstract state a[t] is represented in terms of the concrete state 
, which is a field not of the object t but of the separate object b[t] . The 
field b is called a pivot field. Pivot fields introduce a level of indirection that 
makes dynamic dependencies more complicated than static dependencies. Static 
dependencies allow the representation of an abstraction to be divided among sev- 
eral modules; dynamic dependencies allow it also to be divided among several 
dynamically allocated objects. 

For example, sequences are useful abstractions. To define sequences and then 
use them in different ways is a bottom-up approach and leads to the use of dynamic 
dependencies. To see this, consider a set type Set.T implemented in terms of a 
sequence type Seq.T . Somewhere in the set implementation, there will be a field, 
say q , declared as 

var q: Set.T -> Seq.T 

The representation of the validity and state of a set s will inevitably involve prop- 
erties of the sequence q[s] . Almost always, for example, set validity requires 
validity of the underlying sequence, in which case we have 

rep Set.valid[s: Set.T] = ... A Seq.valid[q[s]] 

This rep declaration requires the dependency 

depends Set.valid[s: Set.T] on Seq.valid[q[s]] 

which is dynamic, with pivot field q . 

Although we have built a checker that handles dynamic dependencies, we 
don't understand them as well as static dependencies. In particular, we haven't 
proved any soundness theorem about them, and our view of their modularity re- 
quirements is still evolving. 

In this section, we will explain how dynamic dependencies affect functional- 
ization and modifies list desugaring, and then explain what we believe about their 
modularity requirements. 
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7.0 Functionalization 



Functionalization in the presence of dynamic dependencies is analogous to func- 
tionalization in the presence of static dependencies only. Both of the fields in the 
right-hand side of the dynamic dependency become arguments to the abstraction 
function. 

For example, in the presence of the dependencies 

depends a[t] on e[t] 
depends a[t] on c [b[t]] 

the functionalized form of a[x] is 

T.a{e, c, b)[x] 
or, more precisely, taking residues into account, 

T.a{sres, res.a, e, c, b)[x] 

The pointwise axiom for T.a is 

( W, sresO, sresl, res.aO, res.al, eO, el, cO, cl, bO, bl :: 

sres0[t] = sresl[t] A res.a0[t] = res.al[t] A e0[t] = el[t] A 
c0[b0[t]] = cl[M[fl] 
=> 

J-'.aisresO, res.aO, eO, cO, b0)[t] = 
T.a{sres\, res.al, el, cl, b\)[t] ) 

We don't introduce anything like residue variables for dynamic dependencies. 

7.1 Modifies list desugaring 

Unlike functionalization, which is pretty much the same for static and dynamic 
dependencies, modifies list desugaring is surprisingly different in the two cases. 
It has taken us several tries to converge on a desugaring that suits all the examples 
that we know. 

In this subsection, we assume that no abstract variable depends, directly or 
indirectly, on itself. This restriction will be lifted in Section 9.0. 

To explain the issues, we start by exploring the obvious extension of the ap- 
proach for static dependencies, and show how this goes wrong. Then we give what 
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we think is the right desugaring, followed by two more supporting examples. Fi- 
nally, we impose a restriction that seems to be necessary to make the desugaring 
sound. 

Recall the main points of Section 5.1: 

• the definition of closure, 

• the rule that modifies M allows the modification of anything in the closure 
of M , and 

• the modification constraints that enforce the rule. 

We will reuse the second and third points. That is, to accommodate dynamic 
dependencies, we redefine closure and leave everything else the same. 

The need to close upwards. Recall that a set of terms M is statically closed in 
a scope D if it satisfies the property 

a[E] e M a "depends a[t] on c[tT efl 4 c[E] e M (14) 

The obvious extension to include dynamic dependencies is to require in addition: 

a[E] e M a "depends a[t] on c[b[tfl" eD =)• c[b[E]] e M (15) 

To give this new closure a name, we define a set of terms M to be downward 
closed in a scope D if it satisfies (14) and (15). Will we get a good desugaring 
if we replace "static closure" with "downward closure" in Section 5.1? Unfortu- 
nately not. 

To explain why the replacement doesn't work, we give a straightforward ex- 
ample of integer sets implemented in terms of extensible integer sequences. Fig- 
ure 8 shows the two interfaces, together with ESC-style specifications. (In these 
interfaces, we have varied our convention and elected not to return anything from 
the init methods.) A simple implementation of all Set objects, in which all ele- 
ments are kept in a sequence with duplicates allowed, begins as shown in Figure 9. 

The whole point of this example is: what will be the effective modifies list used 
in reasoning about the call to Seq.init in the body of Set. init ? Since Seq.init(sq) 
modifies valid[sq] , state[sq] , and length[sq] , the modifies list (before closure) 
of the call q[st].init() is 

modifies Seq.valid[q[st]], Seq.state[q[st]], Seq.length[q[st]] 
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unit Set 
type T 

spec var valid: T -> bool 
spec var state: T -> any 
proc init(st: T) 

modifies va//d|s?], stated] 

ensures va/z'd'[.sf] 
proc insertist: T, i: int) 

requires valid[st] 

modifies state[st] 
proc delete(st: T, i: int) 

requires va/z'<i[.5t] 

modifies state[st] 
proc member (st: T, i: int): bool 

requires valid[st] 

unit Seg 
typeT 

spec var valid: T -> bool 
spec var length: T -> int 
spec var state: T -> any 
proc init(sq: T) 

modifies vataifsg], stated], length[sq] 

ensures va/ta"[sg] A length' [sq] = 0 
proc addhi(sq: T, i: int) 

requires va/zdlsg] 

modifies stated] , /eHgta[sg] 

ensures length' [sq] = length[sq] + 1 
proc get(sq: T, i: int): int 

requires valid[sq] A 0 < i < length[sq] 

Figure 8: The interfaces Set for sets and Seq for sequences. 
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unit Setlmpl import Set, Seq 
var q: Set.T -> Seq.T 

rep valid[st: Set.T] = st ^ nil A q[st] ^ nil A Seq.valid[q[st]] 
depends valid[st: Set.T] on q[st], Seq.valid[q[st]] 
depends state[st: Set.T] on Seq.state[q[st]], Seq.length[q[st]] 
impl init(st: Set.T) is 

q[st] := new(Seq.T) ; q[st].init() 
end 

impl insertist: Set.T, i: int) is q[st].addhi(i) end 



Figure 9: The implementation unit Setlmpl . 

This is also the modifies list after closure, since it is already downward closed 
(not counting residues, which we will ignore since they are irrelevant to this ex- 
ample). Transforming the closed modifies list into modification constraints, the 
postcondition of the rewritten specification is 

ensures {V sqv :: Seq.valid[sqv] = Seq. valid' [sqv] v sqv = q[st] ) A 
( V sqv :: Seq.state[sqv] = Seq. state' [sqv] v sqv = q[st] ) A 
( V sqv :: Seq.length[sqv] = Seq. length' [sqv] V sqv = q[st] ) A 
(V stv :: Set .valid[stv] = Set. valid' [stv] ) A 
(V stv :: Set .state[stv] = Set. state' [stv] ) A 
(V stv :: q[stv] = q'[stv] ) 

The fourth conjunct "protects" the higher- level abstraction Set. valid from a change 
to its representation. In the old world of static dependencies only, this was nec- 
essary, but in the new world with dynamic dependencies, it is preposterous. The 
whole purpose of the Seq.init call is to modify the validity of the enclosing set. 

The example shows that using the downward closure produces too strong an 
ensures clause, that is, too small a closure. 

Let us summarize what the example has shown about the difference between 
static dependencies and dynamic dependencies. In the presence of a static de- 
pendency of a[t] on c[t] , the presence of the term c[x] in the modifies list does 
not, and should not, imply the presence of a[x] in the closure, since the license 
to modify a concrete variable does not imply the license to modify an abstract 
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variable that depends on it. However, in the presence of a dynamic dependency 
of a[t] on c[&|/]] , the example shows that the presence of the term c[x] in the 
modifies list should imply the presence of a[t] in the closure, for any t such that 
b[t] = x . That is, we must close upwards as well as downwards. 

Dynamic closure. In the next few paragraphs, we define the closure that we use 
when desugaring modifies lists in the presence of dynamic dependencies, which 
we call the dynamic closure. We have already indicated that it is larger than the 
downward closure. In fact, it is the union of the downward closure with a portion 
of the upward closure (defined soon). 

Another change from our previous treatment is that the closure will contain 
expressions of the form f~ l . We call these "map inverses", but they are not 
to be thought of as ordinary notation, for example, the notation does not imply 
that / is invertible: they are a syntactic fiction that will be eliminated when the 
closure is transformed into a modification constraint. The elimination is achieved 
by rewriting an equality of the form 

s=fr 1 ur 1 [---u^ 1 [Em\ (i6) 

into 

/ n [--[/ 2 [/iM]]]=£ 

All of the map inverses will be eliminated by this rewriting, because the terms of 
the closure of a modifies list affect the rewritten specification only in modification 
constraints, in which map inverses will occur only in equalities of the form (16). 

The dynamic closure of a modifies list M in a scope D is the union of the 
downward closure of M with the upward closure of the flexible subset of M . 

The flexible subset of a set of terms M in a scope D consists of those terms 
f[E] where D contains no dependency of the form depends a[t] on f[t] . 

A set of terms M is upward closed in a scope D if 

c[E] e M a "depends a[t] on c[t\" efl => a[E] e M 

c[E] e M a "depends a[t] on c[b[t\T 4 e M 

The upward closure of a set of terms is its smallest upward-closed superset. 
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Examples. Let use redo the Set.init example with the new rule. The desugaring 
begins, as before, with the modifies list from the specification, namely 

modifies Seq.valid[q[st]], Seq.state[q[st]], Seq.length[q[st]] 
The dynamic closure of this list includes the term 

Set.vali d[q~ l [q[st]]] 
since the scope includes the dependency 

depends Set.valid[st] on Seq.valid[q[st]] 

This extra term in the closure weakens the modification constraint for Set. valid . 
With the downward closure, the constraint was 

(V stv :: Set.valid[stv] = Set. valid' [stv] ) 
However, with the dynamic closure, the constraint is 

(V stv :: Set.valid[stv] = Set. valid' {stv] v stv = q~ l [q[sf]] ) 
which when map inverses are eliminated becomes 

(V stv :: Set.valid[stv] = Set. valid' [stv] v q[stv] = q[st] ) 

which in turn is functionalized to 

(V stv :: T.Set.valid(sres, res. Set. valid, q, 

T.Seq.valid{sres, res .Seq .valid))[stv] 

T.Set.valid{sres' ', res. Set. valid' , q', 

T.Seq.valid{sres' ', res .Seq .valid'))[stv] 
V q[stv] = q[st] } 

which eliminates the problem since the disjunct q[stv] = q[st] allows the method 
to change the validity of st . (The disjunct also allows the method to change 
the validity of any other set whose q field coincides with the q field of st . 
This accurately reflects the semantics of the situation, and we take it as evidence 
that our rewriting is appropriate. It is a different issue whether the designer of 
Set.T should allow such sharing of the q field — probably not, as explained in 
Section 9.3.) 
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Here is an example to show why the dynamic closure is the union of two clo- 
sures, rather than, for example, the upward closure of the downward closure or 
some kind of bi-directional closure. Suppose that we were doing full functional 
verification instead of extended static checking only, and that sets were repre- 
sented by sequences without duplicates. Then we would have the dependency 

depends Set.valid[st] on Seq.state[q[st]] 

since the rep declaration for Set.valid[st] would forbid duplicates in q[st] , which 
is an assertion about Seq.state[q[st]] . In addition, we still have the dependency 

depends Set.state[st] on Seq .state[q[st]] 

If the dynamic closure were the upward closure of the downward closure, then the 
dynamic closure of the modifies list 

modifies Set.state[st] 

would include Set.valid[st] . Thus, in the scope of the implementation, any oper- 
ation that changes the state of a set would be allowed also to modify its validity, 
which would be preposterous. (It would also be unsound, since in the scope of a 
client of the Set interface, such a side effect would be unexpected.) 

Finally, here is an example to show why the dynamic closure contains the full 
upward closure of the flexible terms of a modifies list, rather than a single level. 
Suppose R is a subtype of Rd.T (see Section 4), that 

var rq: R -> Seq.T 

is a sequence- valued field of readers of type R , and that the subtype-specific 
validity of R readers depends on the validity of the associated sequence: 

depends svalid[r: R] on Seq.valid[rq[r]] 

In this scenario, we would argue that a call that modifies Seq.valid[rq[r]] should 
be allowed to modify both svalid[r] and Rd.valid[r] . 

Dependency segregation. Our desugaring of modifies lists requires a restric- 
tion, which we call the dependency segregation restriction: no field c occurs both 
in a static dependency of the form a[t] on c[t] and in a dynamic dependency of 
the form z[s] on c[Z?[5]] . Because of the visibility and top-down requirements, 
this restriction can easily be enforced modularly. 
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To see that this restriction is necessary, consider the following example: 
unit A 

depends a[t] on c[t] 
proc P(t) modifies c[t] 
unit B import A 

depends z[s] on c[fr|>]] 
. . . call t.PQ ■ ■ ■ 

Because c[t] is not in the flexible subset of the modifies list of P , the caller in B 
expects the value of z[& _1 |>]] to be unchanged. However, if the implementation 
of P is placed in unit A (or in any unit where the dynamic dependency is not 
visible), then no modification constraint will be added to the implementation to 
enforce the unchangedness of z . 

The dependency segregation restriction does not seem to rule out any useful 
programs. 

7.2 Modularity requirements for dynamic dependencies 

The visibility and top-down requirements that we impose for static dependencies 
both have analogues for dynamic dependencies, but the analogues are significantly 
different from the originals. One of the differences is that because pivot fields can 
be updated dynamically, several of the requirements for dynamic dependencies 
can be checked only by reasoning about specifications, not by a simple check on 
the placement of declarations. Our checker enforces the requirements of this sort 
by transforming an annotated input program into another annotated program that 
will verify exactly when the input program would verify and the input program 
obeys the requirements. 

Before getting into these deep waters, we describe the one modularity require- 
ment for dynamic dependencies that can be checked simply by looking at the 
placement of declarations. 

Pivot visibility requirement. The pivot visibility requirement requires that a 
dynamic dependency 

depends a[t] on c[b[t]] 
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be visible anywhere b is. 

This can be enforced simply by checking that the dependency is placed in the 
same unit as the declaration of b . 

Here is the reason we impose the requirement. If there were a scope where 
a and b are visible but the dependency is not, then a modification to b[t] could 
change a[t] unexpectedly. The requirement is not burdensome, since the module 
that implements the abstraction a usually declares both the pivot field and the 
dependency. 

It would probably be sound to require only that the dependency be visible 
where both a and b are, but we have not found any examples where the extra 
flexibility of this weaker requirement would be of any engineering use. 

Absence of abstract aliasing. The visibility requirement for static dependen- 
cies prevents unexpected side effects between an abstract variable and its repre- 
sentation. For the dynamic dependency of a[t] on c[&|>]] , the pivot visibility 
requirement prevents unexpected side effects between a and b , but we still need 
to protect against unexpected side effects between a and c . This is the function 
of absence of abstract aliasing. 

For static dependencies, the problem is solved by requiring the dependency to 
be visible anywhere both a and c are, but for dynamic dependencies, this would 
be undesirably strict. For example, consider the sets and sequences described 
earlier. This strict version of the requirement would force the dependency (and 
therefore the pivot field as well) to be declared in the public interface Set instead 
of in the private implementation where they belong. (It is obviously unreasonable 
to place the pivot and dependency declarations in the public interface Seq , since 
sets may not have been envisioned when sequences were defined.) 

To find the right modularity requirement, we focus on the situation that goes 
wrong, and use our judgment as programmers to assign blame. The situation that 
goes wrong is an unexpected side effect between a[t] and c[u] for some values t 
and u . For the side effect to happen, it must be that b[t] = u . For the side effect 
to be unexpected, it must occur in a scope where a and c are visible but the 
dependency is not. Because of the pivot visibility requirement, it must therefore 
be that b is not visible either. 

More formally, we say that abstract aliasing occurs if execution reaches some 
point in the program text where, for some expressions E and F and pivot field b , 
all free variables of E and F are visible, b is not visible, and E = b[F] A E ^ 
nil . Notice that the condition E = b[F] makes sense even outside the scope 
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of b , since b 's value exists even at program points where b is not visible. We 
require that programs be designed so that abstract aliasing does not occur. This 
requirement, together with the pivot visibility requirement, is the analogue for 
dynamic dependencies of the visibility requirement for static dependencies. 

So much for the definition of abstract aliasing. A further question is to find a 
static discipline for avoiding the problem. 

One simple discipline that prevents abstract aliasing would be to forbid com- 
municating a pivot value b[t] into or out of the scope declaring b . All forms of 
communication must be forbidden, including communication via procedure pa- 
rameters, procedure results, and global and heap locations. We say that the value 
of a pivot field transferred into or out of the scope of the field's declaration is 
leaked. 

Unfortunately, the simple discipline of forbidding all leaking is too strict, for 
several reasons. For example, initialization methods occasionally take parameters 
that are stored into pivot fields. Also, methods of container classes must return 
the elements of the container. Most compellingly, to operate on a pivot, an imple- 
mentation of an abstraction must pass the pivot value to the pivot's own methods. 

We have defined a more flexible discipline for avoiding leaking, which solves 
the three problems mentioned in the previous paragraph. But our solution is not 
totally satisfactory, and instead of describing it in this paper, we refer the reader 
to the companion paper Wrestling with rep exposure [7]. 

Disjoint ranges requirement. The disjoint ranges requirement states that pivot 
fields declared in distinct units have disjoint ranges. That is, if b and d are pivot 
fields whose declarations occur in different units, then, at any procedure boundary, 

(Vs,t :: b[s] = d[t] =>• b[s] = nil } 

where s and t range over non- nil objects. The requirement is enforced by rewrit- 
ing pre- and postconditions. 

To motivate the disjoint ranges requirement, we first recall the motivation for 
the top-down requirement for static dependencies. In the presence of the depen- 
dencies 

depends a[t] on c[t] 
depends v[t] on c[t] 

the checker protects related abstractions by adding the postcondition 
v[t] = v'[t] 



48 



to any procedure specified with modifies a[t] . If the dependency of v[t] on c[t] 
were not visible, the checker would be unable to add this postcondition, making 
modular verification unsound. Soundness is achieved for static dependencies by 
imposing the top-down requirement. 

The top-down requirement works for static dependencies, but it would be 
ridiculously strict to generalize it in the obvious way for dynamic dependencies. 
For example, it would be too strict to require that Set.valid be visible wherever 
Seq.valid is, since Set is a higher-level abstraction, which quite possibly was not 
envisioned when Seq was designed. 

The disjoint ranges requirement is the analogue of the top-down requirement, 
but for dynamic instead of static dependencies. Consider the following variables 
and dependencies: 

depends a[t] on c[b[t]] 
depends v[t] on c[d[t]] 

and a procedure P specified with modifies a[t] . Then P is allowed to modify 
a[t] and c[£|>]] , but not v[s] for any s , not even when d[s] = b[t] . If J is 
visible in the scope containing P 's body, then modifies list desugaring adds an 
appropriate conjunct to the postcondition. But if d is not visible in that scope, the 
only way to guarantee that v[s] is unchanged is to guarantee d[s] ^ b[t] , which 
is ensured by the disjoint ranges requirement. 

Swinging pivots restriction. Consider the modifies list 
modifies b[t] 

It gives a procedure the license to modify b , but only at t . More precisely, the 
procedure is required to establish the postcondition 

(Vs :: b 0 [s] = b'[s] v s = t) 

where, in this discussion, we write b' for the final value of b and b 0 for the initial 
value of b . 

Now consider the modifies list 

modifies b[t], c[b[t]] 

It, too, gives a procedure the license to modify b , only at t . In addition, it allows 
the modification of c at one point only. But is this point b 0 [t] or b'[t] ? It is 
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traditional to choose the first alternative, allowing the modification of c only at 
bo[t] , and we follow this tradition. However, the possibility that bo[t] may be 
different from b'[t] causes a difficulty, which we will now describe. 

Consider the following artificial procedure that returns from a reader not the 
current character but the second character: 

proc secondChar{rd: Rd.T): hit 
requires valid[rd] 
modifies state[rd] 
impl secondChar{rd: Rd.T) is 
result := rd.getCharQ ; 
result := rd.getCharQ 
end 

We certainly hope that this implementation will verify: since rd.getCharQ 's 
specification requires valid[rd] and modifies state[rd] , that same specification 
should be satisfied by two calls in a row. Indeed, it does verify in a scope where 
only Rd is imported. 

Unfortunately, the implementation does not verify if RdRep is imported! The 
problem is that, in the presence of the dependencies declared in RdRep, the 
checker will issue a warning because of the possibility that the first call to getChar 
changes buff[rd] and the second call changes the contents of the new buff[rd] . 
Thus the net effect is inconsistent with our interpretation of secondChar 's speci- 
fication 

modifies state[rd] 

since this desugars to 

modifies buff[rd], elems[buff[rd]], . . . 

which allows changing elems[buff 0 [rd]] , but not elems[buff'[rd]] . 

Reversing the tradition does not help: if secondChar \ specification were 
desugared to allow modification of elems at buff'[rd] instead of at bujf 0 [rd] , 
then the checker would warn about the possibility that the first call to getChar 
changes the contents of the buffer and the second call changes the buffer pointer. 

This problem is a failure of modular soundness, which can only be rectified 
in two ways: by changing the proof system so that secondChar does not verify 
when only Rd is imported, or by changing it so that secondChar does verify 
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when RdRep is imported. Our engineering judgment is that the latter course is the 
right one. The best way we have found to achieve this is to impose a rather strict 
requirement that we call the swinging pivots restriction: a procedure specified 
to modify a pivot field is allowed to change it only to nil or to a value newly 
allocated within the procedure. This discipline is enforced formally by adding, 
for each pivot field b , a conjunct to the postcondition of every procedure: 

(Vs :: b 0 [s] = b'[s] V b'[s] = nil v -^alloc 0 [b'[s]] } (17) 

where alloco[x] means the object x was allocated in the pre-state (Section 8.1 
provides more details about alloc). With this postcondition of getChar, the spu- 
rious warnings will not occur, since the problematic control paths are inconsistent 
with the strengthened postcondition. 

As we have described it, the swinging pivots restriction is too strict. For ex- 
ample, the restriction forbids an initialization method from assigning one of its 
parameters to a pivot field in the object being initialized, which is occasionally 
necessary. It is straightforward to revise the swinging pivots restriction to accom- 
modate such assignments, by adding a disjunct to (17), but we won't describe 
it in this paper since it requires the nomenclature defined in Wrestling with rep 
exposure [7]. 

We can envision situations where even the revised restriction is too strict, for 
example, a double-buffered reader implementation in which one buffer is being 
filled while the other is being emptied. But the swinging pivots restriction is the 
best solution to the problem that we know. 



8 Reasoning about types and allocation 

A central issue described in this paper is the rewriting of specifications found in 
a modular program into specifications about which one can reason using standard 
techniques for verifying one-scope programs. Although those techniques have 
been described widely in the literature, there are some areas where we have had 
to innovate in order to build the Modula-3 Extended Static Checker, in particular 
in the areas of reasoning about types and allocation. We describe these techniques 
here, both because some of the techniques related to allocation are new, and be- 
cause this material interacts with the modularity issues discussed in Section 9. 
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8.0 Reasoning about types 



Conditions that the type system guarantees can be assumed by the checker without 
proof. We call such conditions "freeconditions". For example, in checking a 
procedure implementation like 

impl P(n: nat) is . . . end 

we get the free precondition n > 0 . The full story is more complicated, since the 
value of type nat might be a field of some object rather than a simple parameter. 

Therefore, every verification condition R in a scope D is discharged under 
the background predicate for D : 

BackgroundPred D =>• R 

The background predicate is a conjunction of axioms formed from the declarations 
that are visible. This subsection gives a flavor of what the background predicate 
contains. 

For every type T , the background predicate contains the definition of a pred- 
icate symbol is$T , which asserts that its argument is of type T . In addition, for 
each object type T , the background predicate contains a constant tc$T represent- 
ing the typecode of T . If T is declared to be a subtype of an object type U , the 
background predicate will contain the conjunct 

subtype! (tc$T, tc$U) 

For an object type T , is$T is defined by the conjunct 

(V? :: is$T(t) = t = nil v subtype(typecode(t), tc$T) ) 

where subtype is the reflexive, transitive closure of subtype! . 

Data fields are treated as maps from objects to values. For every map type 
T -> U occurring in the program, the background predicate defines a predicate 
symbol field$T$U . One of the axioms about field$T$U asserts that applying a 
map to a value in its domain produces a value in its range: 

{Vf,t :: field$T$U(f) A is$T(t) A t # nil => is$U(f[t]) } 

For the full details of the background predicate of a small object-oriented lan- 
guage, we refer the reader to the axiomatic semantics of Ecstatic [29]. The back- 
ground predicate used for Modula-3 in the Extended Static Checker is similar, but 
more complicated, because, for example, Modula-3 has a larger variety of types. 
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8.1 Reasoning about allocation 

Consider the following specification puzzle: A procedure P takes a filename as 
a parameter, opens the named file, reads four bytes, and returns their value as an 
integer. We would like to specify P with an empty modifies list, since P is essen- 
tially functional from the point of view of the client. However, it is impossible to 
implement P without side effects on allocated data. For example, if a file reader 
is used, its buffer will be changed. 

Our solution is to make it implicit in the specification of every procedure that 
modifications to newly allocated state are allowed. Thus, although P 's modifies 
list is empty, its implementation is allowed to change the fields of the file reader, 
since it allocates that reader (but if P used a pre-existing reader rd , it would have 
to mention state[rd] in the modifies list, as usual). We say that by convention 
we allow "free modification of unused state". In fact, we have already used this 
convention: BlankRd.init modifies the contents of the buffer. This is allowed 
by our convention, because the buffer is newly allocated, but it would have been 
inconsistent with the modifies list otherwise. 

We believe this convention is sound with respect to the standard operational 
semantics, but we have neither proved it nor noticed that anyone else has. 

The convention affects the desugaring of specifications. To describe this in 
more detail, we must explain the semantics of allocation. Since successive calls 
to the storage allocator return different results, it must be that the calls have some 
side effect. Informally, the side effect is to extend the set of allocated objects. In 
the formal semantics, the side effect is to change the "allocated" property of the 
returned object from false to true . We model this property with the predeclared 
boolean object field alloc . 

The program expression new(T) is sugar for 

var x in 

x ^ nil A ->alloc[x] A x e T 

alloc[x] := true ; result := x 
end 

that is, nondeterministically choosing any non- nil , unallocated object of type T , 
and allocating and returning it. 

The modifies list of every procedure implicitly contains alloc , and the post- 
condition of every procedure implicitly includes 

(Vs :: alloc[s] =>• alloc'[s] ) 
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that is, the procedure can allocate objects, but not deallocate them (we assume 
the usual fiction of garbage collected languages wherein objects are allocated but 
never deallocated). 

Recall that, for every field g , a modifies list desugars to a conjunct in the 
postcondition of the form 

( Vs :: g[s] = g'[s] v s = E Q v s = E x v . . . } 

where the E 's are the modification points allowed for g by the modifies list. With 
our allocation convention, this conjunct becomes 

(Vs :: g[s] = g'[s] v -^alloc[s] v s = E 0 v s = E x v . . . } 

This allows the procedure to modify g at any newly allocated object. 

The specification language admits assertions that quantify over all objects of a 
particular type. Such assertions are considered by convention to apply to allocated 
objects only. For example, a universal quantification {Vx:T :: P(x) ) occurring 
in a specification is desugared into 

(Vx:T :: alloc[x] => P(x) } 

except if it occurs in a postcondition, in which case it is desugared into 

(Vx:T :: alloc'[x] => P{x) > 

These kinds of assertions are not common in pre- or postconditions, but they are 
common in program invariants, which will be discussed in Section 9.3. 

Unlike the mini-language used in this paper, many programming languages 
allow declarations to specify default values for object fields. These will become 
important when we discuss program invariants in Section 9.3. Taking default 
values into account, the desugaring of new must be altered slightly from the 
version given above. Suppose, for example, that / is one of T 's fields, and that 
the default value of / is the constant C . Then new(r) is sugar for 

var x in 

x ^ nil A -*alloc[x\ A x e T A f[x] = C 

alloc[x] := true ; result := x 
end 

This desugaring nondeterministically chooses an object whose / field has the 
right value. (We prefer this to an alternative desugaring which assigns f[x] := C 
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after choosing x . Our version reduces the number of assignments, which speeds 
mechanical checking.) 

The story we have told so far about new is not new. For example, our story 
is essentially equivalent to that given by Hoare and Wirth in their classic paper on 
an axiomatic semantics for Pascal [19]. We were surprised to find, when applying 
our checker to the Modula-3 library, that the story doesn't work. The following 
artificial program illustrates the problem: 

type T, U 
var/: T -> U 

proc P(t: T) requires t ^ nil 
impl P(t: T) is 
var u: U in 
u := new(t/) ; 
assert f[t] ^ u 
end 

end 

Procedure P , which takes an object t as a parameter and allocates a new object 
u , will crash if the / field of t is u . As programmers, we know this won't ever 
happen, but nothing we have said so far allows this procedure to be verified. We 
have ensured that new returns a previously unallocated object, but we have not 
ensured that all reachable objects are allocated. This problem seems to be less 
appreciated than the more easily solved problem of ensuring that new returns a 
previously unallocated object. 

The background predicate helps, since we can arrange that it provide the as- 
sumption alloc[t] for each parameter or global variable of an object type. But as 
the example shows, this is not sufficient, since alloc\f\f\\ does not follow log- 
ically from alloc[t] . The basic idea of our solution is to allow the checker to 
assume that fields of allocated objects are themselves allocated, that is, that for 
every declared field / whose range type is an object type, alloc is closed under 
/ . It is not enough to assume this condition once and for all in the background 
predicate, since both alloc and / are mutable. Instead, the closure condition is 
an implicit pre- and postcondition of every procedure, including new . We will 
not describe the details here, since they are not particularly relevant to modular 
verification. Instead, we refer interested readers to the axiomatic semantics of 
Ecstatic [29]. 
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9 Further challenges 



Static and dynamic dependencies allow us to check many parts of the Modula-3 
run-time library that we were unable to check without them. But there remain 
programming paradigms that are used in practice and seem sound and modular to 
which our approach does not apply. This section describes some of these chal- 
lenges and some tentative ideas we have for addressing them. 

9.0 Cyclic dependencies 

Dynamic dependencies give rise to the possibility of cyclic dependencies, that is, 
an abstract variable may depend on itself indirectly, via some pivot fields. Indeed, 
this happens in the case of a "filter" object that "forwards" method calls to an 
instance of one of its supertypes. For example, consider a DOSRd subtype of 
Rd that returns all the characters of a given child reader, but with carriage return 
characters filtered out: 

unit DOSRd import Rd 
type T <: Rd.T 
proc init{drd: T, rd:Rd.T):T 

requires valid[rd] 

modifies valid[drd] 

ensures valid' [drd] A result = drd 

(For simplicity, we're ignoring state.) The expression new (DOSRd. T).init(rd) 
allocates, initializes, and returns a new DOS reader with child reader rd . The 
implementation of DOS readers will need to store the child reader in some field 
of the DOS reader, say ch : 

var ch: DOSRd. T -> Rd.T 

The implementation will also have to give the representation of svalid for DOS 
readers, which will include a conjunct expressing that the child is valid: 

rep svalid[drd: DOSRd. T] = ... A valid[ch[drd]] 

This requires the dynamic dependency 

depends svalid[drd: DOSRd.T] on valid[ch[drd]] 
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Combined with the static dependency of valid[rd] on svalid[rd] in RdRep , this 
produces a cycle of dependencies. 

To accommodate cyclic dependencies, we make two changes to our proof sys- 
tem. We will describe the two changes for the case that there is exactly one pivot 
field involved in any cycle. This is the only case that we have implemented in 
ESC, although we believe that the ideas could be generalized. 

The first change is in taking the closure of a modifies list. We need to make 
some change to prevent the closure from being infinite. We introduce two new 
notations allowed in closures: /*[/] and f~*[t] . Intuitively, they represent the set 
of terms 

t, f[t], f\f[t]], ... 
and the set of terms 

t, /[-% /rVr 1 ;]], ... 

respectively. These notations appear in the closures of modifies list, but they are 
fictions that are eliminated when the closures are transformed into postconditions. 
Since we assume only one pivot field per cycle, the infinite set of terms produced 
by the closure rules described previously can be summarized in a finite set of terms 
involving the new notations. For example, in the context of the implementation of 
DOS readers, the modifies list 

modifies valid[drd] 

has the closure 

valid[ch* [drd] ] , svalid[ch* [drd] ] , 
valid[ch~*[drd]], svalid[ch~*[ch~ l [drd]]] 

Recall that modifies lists are closed, and then closed modifies lists are turned into 
modification constraints in postconditions. Thus, to eliminate our new notations, 
we must show how to rewrite them into modification constraints. The license to 
modify gives rise to the postcondition contribution 

b 

( Vs :: a[s] = d[s] v t — > s ) 

nil 

b 

where the notation t — > s , read " t reaches s via (applications of) b , not going 

X 

through x", is defined by Nelson [42]. Similarly, the license to modify a[&~*|>]] 
gives rise to the postcondition contribution 

( Vs :: a[s] = a'[s] v s t ) 

nil 
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The second change to our proof system is to the pointwise axiom for any 
abstract variable involved in a cycle of dependencies. We will describe the change 
by means of an example. To set the stage, we consider first an example with a 
dynamic but non-cyclic dependency, say 

depends a[t] on e[t] 
depends a[t] on c[b[t]] 

The pointwise axiom for a (leaving out residues) is 

(Vs,eO,el,cO,cl,M),M :: eO[s] = el[s] A cO[bO[s]] = cl[bl[s]] 

=> F.a(eO, cO, bO)[s] = T.a{e\, cl, bl)[s] ) 

Now let the dynamic dependency be cyclic: 

depends a[t] on e[t] 
depends a[t] on a[&|>]] 

The new pointwise axiom for a (leaving out residues) is 

(Vs,eO,el,bO,bl :: 

(Vr :: s r =>• eO[r] = el[r] A bO[r] = bl[r] ) 

nil 

==> F.a(eO, bO)[s] = T.a{e\, bl)[s] } 

That is, a[t] 's value depends only on the e and b fields of objects reachable from 
t via b. 

We will illustrate this pointwise axiom by showing the verification of the init 
method of DOS readers, implemented as: 

impl init(drd: T, rd: Rd.T): T is 

ch[drd] := rd ; lo[drd] := 0 ; ... ; result := drd 
end 

where we assume the elided code initializes the cur , hi , and buff fields of drd to 
satisfy the validity requirements given in RdRep . The first part of this verification 
is showing that the assignment to the ch field establishes svalid[drd] . This is 
easy since the init method requires valid[rd] as a precondition. The second 
part is showing that the assignment does not affect the validity of any other reader 
(except as allowed by the modifies list). As we have already remarked, the closure 
of the modifies list includes 

valid[ch*[drd] ] , valid[ch~* [drd] ] 
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which produces the postcondition 

ch ch 

(Vs :: valid[s] = valid [s] v drd — > s v s — > drd ) 

nil nil 

which is functionalized to 

(V* :: T.validich, lo, . . .)[s] = T.valid(ch! , lo', . . .)[s] 
v drd s v s drd ) 

nil nil 

which follows from the pointwise axiom for valid , which is 

(Vs,chO,chl,loO, lol :: 

( Vr :: s ^> r ==> chO[r] = chl[r] A loO[r] = lol[r] A ...) 

nil 

T.valid(chQ, loO, . . .)[s] = T.validichX, lol, . . .)[s] ) 

We leave the proof to the reader. 

In the verification of the init method of DOS readers, no properties of the 
reachability predicate were used: it might as well have been an uninterpreted 
predicate. Properties of the reachability predicate come into play when verifying 
a non-trivial operation on the DOS reader whose implementation modifies the 
child reader (for example the refill method, which recursively invokes the refill 
method of the child). 

In summary, we have described the essential ideas of a proof system for cyclic 
dependencies. More details are described by Rajeev Joshi [24]. At least two 
problems still remain: Cyclic dependencies with more than one pivot field per 
cycle require some generalization. Also, even with just one pivot field per cycle, 
our rewriting produces verification conditions that are beyond the limit of what 
our automatic theorem prover can handle efficiently. 

9.1 Yet more dependencies 

We have concentrated on static and dynamic dependencies because they play a 
central role in the patterns of abstractions in the library programs we took as test 
cases in the ESC project, not because we can't imagine other kinds of dependen- 
cies. In this section, we sketch what we know about other dependencies. 
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If a global abstract variable (not a field) depends on a global concrete variable 
(not a field), we call it an entire dependency. For example, 

spec var k: int 
var m, n: nat 
rep k = m — n 
depends k on m, n 

This kind of abstraction occurs frequently in papers on data refinement, but in 
practice we have found static and dynamic dependencies far more frequent. One 
place in which entire dependencies are useful is in reasoning about module initial- 
ization, which we will address in Section 9.2. We have a soundness theorem for 
entire dependencies, and the modularity requirements are essentially the same as 
those for static dependencies, that is, the dependency of a on c must be placed 
in the unit that declares c [28]. 

If an abstract field (not a global variable) depends on a global concrete variable 
(not a field), we have a dependency of the form 

depends a[t] on g 

As an example of how this might come up, consider an abstract type whose in- 
stances contain unique id fields. Each id field is initialized from a global counter, 
gcount . This might well lead to a representation of validity of the form 

rep valid[t] = ... A id[t] < gcount 

which in turn would require a dependency of the form 

depends valid[t] on gcount 

However, the soundness of these dependencies is problematical, and our current 
view is that they are not useful and should be forbidden. To specify a data type 
containing unique identifiers, we recommend using program invariants, as will be 
described in Section 9.3. 

If an abstract field depends on concrete fields of the elements of an array, 
we have an array dependency. We would suggest overloading the notation for 
dynamic dependencies: if b[t] has type array[£/] and c is a field with index 
type U , then 

depends a[t] on c[b[t]] 
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is an array dependency that allows a[t] to depend on the sequence of values 



c[b[t][0]], c[b[t][lM ... 

So an array dependency seems akin to a dynamic dependency, but with an array 
of pivots instead of just one. 

As an example of an array dependency, consider a type T representing sets 
of elements of type E . Suppose that the implementation automatically enlarges 
itself when necessary, and that enlarging requires rehashing the current elements, 
and that rehashing an element requires that the element be valid. Then, the validity 
of the set will require the validity of all its elements. If the elements are held in an 
array, say b , then the validity of the set will have the form 

rep T.valid[t: T] = 

... A (V/ :: 0 < i < number (b[t]) =>• E .valid[b[t][i]] ) 

which involves the array dependency 

depends T.valid[t: T] on E .valid[b[t]] 

We suspect that array dependencies are a straightforward generalization of dy- 
namic dependencies, but we have not investigated them thoroughly. 
One can imagine many other kinds of dependencies, for example, 

depends a[t] on c[^[J[?]]] 

But we have never been able to make a strong case that such dependencies are 
useful. 

9.2 Checking initialization order 

Initializing global data is more complicated in a multi-module program than in a 
single-module program and is a common source of programming errors. Some 
of the procedures in a module require that the module's globals be initialized, but 
generally not all of them: for example, any procedure that is used in performing 
the initialization. Thus, there are two classes of procedures: those that require 
prior initialization of the module and those that don't. A common error is to 
inadvertently call a procedure of the first class before initialization is complete, 
either through confusion over which class a procedure is in, or because the linker 
initializes the modules in an unexpected order. 
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We suggest that abstraction and specification can help in solving this prob- 
lem. The idea is to introduce into the interface of each module a boolean abstract 
variable, called an init variable, which means the module has been initialized. 
Procedures of the first class require the init variable as a precondition, while those 
of the second class do not. The purpose of a module body is to ensure an init vari- 
able as a postcondition; to achieve this, it may call other procedures that modify 
and ensure the init variable. 

A programmer can also require one or more init variables of other modules as 
preconditions of the module body. The linker calls the module bodies in an order 
such that each body's precondition is established before it is called, or reports a 
cycle if this is impossible. Each module provides a rep declaration that connects 
its init variable to the globals of the module, so occurrences of init variables in 
specifications are desugared like any other abstract variable. 

An init variable generally depends on the global variables in the module. 
These dependencies satisfy the modularity requirements for entire dependencies 
since they are placed in the same units as the declarations of the globals, and thus 
present no problem to modular verification. An init variable may also depend on 
other init variables, since 

rep Minit = Ninit A . . . 

where Minit and Ninit are the init variables of two modules M and N, is a 
simple way of giving M 's procedures of the first class the right to call N 's proce- 
dures of the first class. Unfortunately, the dependency of Minit on Ninit is most 
naturally placed in the implementation of module M , a unit that declares neither 
Minit nor Ninit . Thus, this dependency violates both the visibility and top-down 
requirements, which in general destroys soundness. We have several ideas for 
restoring soundness while allowing init variables to depend on one another. These 
ideas are based on the observation that init variables change only from false to 
true . But we have not proved a soundness theorem. 

9.3 Invariants 

In practice, almost all pivot fields are injective (one-to-one), that is, if b is a pivot 
field and u and v are distinct objects in the domain of b , then b[u] and b[v] are 
distinct (or they are both nil ). The reason for this is easily seen by considering the 
prototypical example involving a dynamic dependency, shown in Figure 10. The 
call to R from P modifies c[&|>]] . This affects the value of a[t] . If the pivot field 
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unit M 



typeT 

spec var a:T -> ... 

proc P(f: T) modifies a[t] 

unit N 
type U 

spec var c: C/ -> . . . 

proc7?(j<: [/) modifies c[w] 

unit Mlmpl import M, iV 
var b:T ^ U 
depends a[t: T] on c[M?]] 

impl P(t: T) is end 
Figure 10: A prototypical example involving a dynamic dependency. 
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b were not injective, it would also affect a[u] for any u such that b[u] = b[t] . 
In general, when a[t] is modified by changing part of its representation c[Z?[?]] , 
the only hope for showing that the modification obeys the modifies list 

modifies a[t] 

is to require the injectivity of b . 

Note that although we find injectivity necessary to be able to verify interesting 
programs, we have not found injectivity to be a requirement for soundness. 

By the way, it is surprisingly difficult to verify a procedure that initializes an 
injective field. While showing that a command like 

b[t] := new(L0 

maintains the injectivity of b is easy, a command like 

b[t] := NewUQ 

does not verify, even if procedure NewU is specified to ensure -W/oc[result] A 
alloc' [result] . The checker dreams up the possibility that NewU allocates a new 
U object, squirrels it away into some b field, and then returns it. To cope with 
this problem, we enrich the specification language with the expression virgin[x] , 
which means that x is not, and has never been, the value of any object field or 
global variable. The details are found in a paper by Leino and Stata [34]. 

How should a programmer use the specification language to record the design 
decision that a field is to be injective? One might first try to include this as part of 
the representation of an object's validity, producing a rep declaration like 

rep valid[t: T] = ... A (b[t] = nil v ( Vs: T :: s # t => b[s] # b[t] }) 

But this seems problematical. It makes valid[t] depend not just on b[t] , but on 
b[s] for all s of the appropriate type. It seems perverse to think of this unbounded 
collection of b[s] 's to be part of the "representation" of valid[t] . 

A simpler and better strategy is to extend the specification language with the 
notion of a program invariant: a declaration of the form 

invariant J 

records the intention that the predicate J hold at every procedure call and return. 
For example, to specify the injectivity of b , the following program invariant can 
be used: 

invariant ( W, u: T :: t ^ nil A u ^ nil A t ^ u 

=>• b[t] # b[u] v b[t] = nil ) 
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The checker enforces program invariants with two checks. First, it checks 
that J is true at the "beginning of time". Second, it checks that every procedure 
respects J (assuming that all the procedures it calls respect J ), that is, it conjoins 
J to the pre- and postcondition of every procedure implementation and procedure 
call. 

The beginning-of-time test is straightforward and presents no modularity prob- 
lems. It consists of the following proof obligation for each declared program in- 
variant J: 

(V? :: t = mi v -<alloc[t] } =>• J 

That is, J must hold in a state in which no non- nil objects have been allocated. 
More precisely, this proof obligation must follow from the background predicate. 
If J contains free variables of primitive types like integers, then it must hold 
regardless of their values. To enforce invariants about global variables, the init- 
vars technique described in Section 9.2 is more useful. In our experience, we 
mostly use program invariants to assert universally quantified properties of objects 
of a certain type, like injectivity. In this case, the beginning-of-time test passes 
trivially. 

The second test, that every procedure respects J , involves subtle modularity 
issues. The basic idea is simple: when in a scope D the checker desugars a spec- 
ification (either in reasoning about a procedure call or in checking a procedure 
implementation), it adds to the pre- and postcondition all invariants whose decla- 
rations are in D . However, if the program consists of a single global scope, then 
the soundness of this approach is clear: the change to the pre- and postconditions 
is the same for reasoning about the calls as for checking the implementations. If 
the program consists of many scopes, then modularity requirements must be im- 
posed to achieve soundness, by ensuring that primitive steps in a scope where the 
invariant is not visible cannot falsify the invariant. We will build up to the correct 
modularity requirements in stages. To begin with, we assume that the invariant 
contains concrete variables only. 

The first modularity requirement for invariants that comes to mind is: 

a program invariant must be declared near all of its free variables. 

Two declarations are near one another if they are contained in the same unit. It 
follows that they are visible in the same scopes. 

This simple modularity requirement achieves soundness because an invariant 
cannot be falsified except by modifying its free variables. Thus, those procedures 
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whose implementation lies outside the scope of the invariant preserve the invariant 
because they cannot mention any of its free variables. The rest of the procedures 
are proved to maintain the invariant. 

Unfortunately, this simple requirement is too strong because of the special 
concrete variable alloc , which represents the set of allocated objects and occurs 
implicitly in almost all invariants: recall from Section 8.1 that a quantification 

(Vt:T :: ... } 

is desugared to 

(Vf.T :: alloc[t] =>...) 

Consequently, it is necessary to loosen the simple rule to allow program invariants 
to mention alloc . This introduces the danger of a procedure falsifying an invariant 
invisible to it by modifying alloc . We address this difficulty by observing that the 
only way a procedure can directly modify alloc is by performing an allocation, 
and we can demand of an invariant that it be maintained by any allocation in any 
portion of the program in which it is not visible. To this end, we say that an 
invariant J passes the blind allocation test for a type T if J is invariant under 
new(T) . 

This brings us to the second version of the modularity requirement for invari- 
ants: 

(0) a program invariant must be declared near all of its free concrete variables, 
except alloc , and 

(1) for all types T , either (a) T is declared near the invariant, or (b) the invari- 
ant passes the blind allocation test for T , or (c) T is not mentioned in the 
invariant. 

Here's a sketch of a justification for this version of the modularity requirement: 
Because of (0), the only invariant-falsifying primitive steps that we need to worry 
about are those that modify alloc , that is, expressions of the form new(r) for 
some type T . But it is impossible for the expression new(r) to falsify the in- 
variant, because for such a T , neither (a) nor (b) nor (c) could hold: not (a), since 
if T is declared near the invariant, the invariant is visible wherever new(T) can 
be called; not (b), since the blind allocation test explicitly checks that new(r) 
maintains the invariant; and not (c), since new(r) cannot falsify the invariant if 
the invariant doesn't mention T and passes the blind allocation test for T . 
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In order to pass the blind allocation test, a programmer must choose appro- 
priate default values for the fields of an object type. For example, if a pivot is 
specified to be injective, its default value should be nil . 

Let us return to a problem that we touched on in Section 9.1, namely the 
problem of declaring a data type containing unique identifiers: 

unit U 
typeT 

spec var valid: T -> bool 
proc initit: T): T 

modifies valid[t] 

ensures valid' [t] A result = t 

unit Ulmpl import U 
var id:T -> int 
. . . (other fields) . . . 
rep valid[t: T] = ... 
var gcount: int 
imp\ init(t: T):T is 

id[t] := gcount ; gcount := gcount + 1 

result := t 
end 

To record the design decisions about id and gcount , one can add to Ulmpl the 
program invariants: 

invariant ( V t: T : : t ^ nil A valid[t] =>• id[t] < gcount } 
invariant ( W, u: T :: 

t ^ nil A u 7^ nil A valid[t] A valid[u] A t u 
id[t] id[u] ) 

In this approach, the statements about id and gcount that were problematical to 
place in the rep declaration (see Section 9.1) have been moved into program in- 
variants. The rep declaration for valid[t] concerns only fields of t. This seems 
an improvement, but this approach still has two problems: one is giving the pub- 
lic init method the license to modify the private variable gcount, the other is 
allowing the abstract variable valid to appear in a program invariant. 
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To solve the first problem, we can introduce an abstract variable, say istate 
for internal state, in the interface U : 

spec var istate: any 

We then allow init to modify istate , but istate has no other occurrences in the 
interface: 

proc init(t: T): T 

modifies vali d[t] , istate 
ensures valid' [t] A result = t 

Finally, we add the entire dependency of istate on gcount to the module Ulmpl : 

depends istate on gcount 

which by downward closure gives init the license to modify gcount . 

The second problem is that the invariants mention valid[t] , but so far we have 
considered invariants containing concrete variables only. We cannot just eliminate 
the occurrences of valid[t] , since no default value for id will make the second 
invariant pass the blind allocation test for T . The blind allocation test is needed, 
since T is mentioned in the invariant but T and the invariant are not declared 
near one another. 

One way to solve the second problem is to allow abstract variables in program 
invariants. We believe that it is sound to do so, provided that the invariant satisfies 
(0) and (1) from above, and also, for each abstract variable a appearing in the 
invariant: 

(2) all dependencies of a are static, and 

(3) either (a) the invariant is declared near a , or (b) the invariant is declared 
near every rep declaration of a and near every dependency of a . 

However, this story is getting more complicated than we like. Perhaps it is best 
simply to forbid abstract variables from appearing in program invariants. If we 
do, we need some other way of dealing with the occurrences of valid[t] in the 
program invariants in the unique identifiers example. This we can do simply by 
inlining them, that is, by replacing valid[t] by whatever expression is given as its 
rep. Although awkward, this entails no loss of modularity or information hiding, 
since the invariants occur in a scope ( Ulmpl ) where the representation of vali d[t] 
is visible. 
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10 Implementation status 



Almost everything described in this paper has been implemented in the Modula-3 
Extended Static Checker. Exceptions are: 

0. the checker implements only the individual residues, not the shared residue 
sres described in Section 6 beginning on page 34, 

1 . the checker does not enforce the dependency segregation restriction of Sec- 
tion 7.1 on page 45, but instead uses a more general way of computing the 
dynamic closure ("upward closure of dynamic predecessors"), which does 
not necessitate the restriction, 

2. the checker does not enforce the disjoint ranges requirement of Section 7.2 
(and as mentioned in that section, we leave it to the programmer to avoid 
abstract aliasing), and 

3. the checker does not implement the initialization order checking of Sec- 
tion 9.2. 

Our experience with the checker is described in more detail in our companion 
paper [8]. We have applied the checker to thousands of lines of code, both from 
the Modula-3 libraries and from programs that use the libraries. In specifying the 
libraries, we constantly used static and dynamic dependencies. 

After experimenting with our Modula-3 checker, we embarked on another 
project to build an extended static checker for Java [13, 32]. In the ESC/Java 
project, we circumvented most of the difficulties described in this paper by omit- 
ting data abstraction from the annotation language. To partially make up for the 
omission, we provide object invariants [33] and ghost variables, but the fundamen- 
tal basis of our decision was to accept less thorough checking in order to produce 
a simpler checker. 

11 Related work 

Most work on data abstraction seems to be directed at one of two goals: algorithm 
design or structuring large systems. 

When data abstraction is used for algorithm design, the representation is "in- 
lined" into the site of use as the refinement step of the design [5, 16, 25, 22, 39, 
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17, 14]. Consequently, the work on this kind of data abstraction is largely uncon- 
nected with the large system structuring problems that we are concerned with in 
this paper. This is not to deny that the underlying mathematics of data abstraction 
applies to both enterprises. Indeed, our first verification condition generator did 
not use explicit functionalization of abstract variables but instead used the "change 
of coordinates" approach common in algorithm refinement. However, we found 
that the result was that our theorem-prover was constantly forced to apply the 
"one-point rule" and that for our purposes, explicit functionalization is preferred. 

Turning to data abstraction for the purpose of structuring large systems, the 
earliest treatments were in contexts where there was no independent information- 
hiding mechanism (like our units) and therefore the problems addressed in the 
present paper did not arise, or were ignored in the semi-formal treatments in the 
literature. These treatments include Milner's definition of simulation [37], Hoare's 
classic treatment of abstraction functions [18], and the influential work of Liskov 
and Guttag and the rest of the CLU community [35]. 

The first programming language to support information hiding in the way our 
units do was Mesa [38], with its definition modules and implementation modules. 
The Mesa designers appear to have been influenced by Parnas's classic paper on 
decomposing systems into modules [46]. Mesa in turn influenced Modula [50], 
Modula-2 [51], Modula-3 [44], Oberon-2 [40], and Ada [4]. Ernst, Hookway, 
and Ogden have studied the problem of specifying Modula-2 programs where the 
objects of a module may share some global state [12]. These authors share our 
concern for modular verification, but the possible scopes they consider are not rich 
enough to allow subclasses or the RdRep interface of our example. 

Another, rather different, approach of hiding information is to classify decla- 
rations as public or private. This approach is used in Oberon [49], C++ [11], and 
Java [15]. In the course of the ESC/Java project [13, 32], we used the modularity 
requirements of the units approach to guide our design for visibility of invariants 
in the public/private approach [33]. 

One of the central ideas of this paper, explicit dependency declarations, were 
introduced in Leino's PhD thesis [28] in 1995. Between that time and this, they 
have been applied in a number of contexts: they played a central role in ESC for 
Modula-3 [8], and they were incorporated in the specification languages JML [27] 
and Larch/C++ [26] and in the programming logic of Miiller and Poetzsch-Heffter 
[41] . Another application (or reformulation) of dependency declarations is Leino's 
technique of Data Groups [30] . 

As described in Section 7.2, our best attempt at a solution to the problem 
of abstract aliasing [7] is not fully satisfactory. We do find that our framework 
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of modular soundness and dynamic dependencies has allowed us to give a more 
incisive definition of the problem than other approaches in the literature, such as 
Hogg's Islands [20], Almeida's Balloons [3], Utting's Extended Local Stores [48], 
the Flexible Aliasing Protection of Noble et al. [45], and Boyland's Alias Bury- 
ing [6]. 

A few other researchers have employed declarations similar to our depends 
declaration connecting an abstract variable to the (more) concrete variables in its 
representation. Daniel Jackson's Aspect system features dependencies much like 
ours, but his motivation seems to be to avoid the need for reasoning about the de- 
tails of the actual representation, whereas we have argued that dependency decla- 
rations are necessary even in the presence of full representation declarations [21]. 
The COLD specification language of Jonkers includes abstract variables (called 
functions) and dependency declarations between them, but COLD seems not to 
allow an abstract variable to appear in a modifies list, so it doesn't address many 
of the problems we have wrestled with [23]. 

12 Conclusions 

We have applied precise formal methods to systems programs that are typical 
examples of the programming techniques used by careful and experienced con- 
temporary programmers. We found that the formal methods described in the ver- 
ification literature are inadequate to deal with the patterns of data abstraction and 
modularization in these programs. We have developed new formal methods to 
address these shortcomings. 

Central to the new methods is the concept of an abstraction dependency, which 
is a kind of abstraction of an abstraction function, in the same sense that an opaque 
type is an abstraction of a concrete type. A dependency specifies one or more of 
the variables that occur in an abstraction function, but hides the detailed definition 
of the function. Just as an opaque type may be widely visible in a multi-module 
program, while the corresponding concrete type may be visible only narrowly, we 
discovered that it is often useful to make a dependency more widely visible than 
the abstraction function itself. 

Different kinds of abstraction dependencies occur in different styles of design. 
Top-down programming leads to static dependencies, where an abstract field of 
an object is represented in terms of other fields of that same object. Bottom- 
up programming with reusable libraries leads to dynamic dependencies, where 
an abstract field of an object is represented in terms of fields of other objects, 
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reachable indirectly from the first object. 

We have shown how to verify programs in the presence of static and dynamic 
dependencies by rewriting modifies lists, preconditions, and postconditions. 

For static dependencies, we have two simple modularity requirements, which 
are laws for the placement of dependency declarations in a multi-module program. 
The requirements do not seem to preclude any useful designs, and we have a for- 
mal proof of modular soundness for the requirements. The formal proof makes 
use of our identification of modular soundness with the monotonicity of verifiabil- 
ity with respect to scope. For dynamic dependencies, we have several modularity 
requirements, but no soundness theorem, nor any confidence that the list of re- 
quirements is complete. 

In our experience with static checking of contemporary program libraries, we 
have found that we use dependencies constantly in our annotations. We have 
also found that dependencies provide a new perspective on old problems like the 
problem of encapsulation and rep exposure. 
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Appendix: Modular soundness of 
static dependencies 

This appendix provides a proof that the treatment of static dependencies in Sec- 
tions 5 and 6 is monotonic with respect to scope, that is, that it adheres to modular 
soundness. In Part I, we describe the user input, that is, programs and their decla- 
rations. In Part II, we describe how a user program is transformed into verification 
conditions (VCs). In Part III, we state the soundness theorem and give its proof. 
The soundness theorem is that VC generation is monotonic with respect to scope. 
Our overall proof strategy is to apply semantic-preserving, syntactic transforma- 
tions to a valid VC generated in a small scope, arriving at the VC generated in a 
larger scope. We conclude with Part IV, in which we reflect on the theorem and 
its proof. 

Parti 

User input 

AO Declarations 

A declaration introduces a name for a type, field, or method and/or specifies prop- 
erties of such entities. 

Types play almost no role in this appendix, but for completeness, we repeat 
here the two kinds of (object) type declarations: 

type T 
type T < : U 

where U names an object type. These introduce the name T for an object type 
about which nothing is known, except, in the second case, that T is a subtype of 
the object type U . In addition to object types declared in this way, we postulate a 
set of predeclared types ( int , bool , etc.). 
A concrete field declaration has the form 

var r.T -> U 
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where T is an object type and U is a type. This introduces the name c for a 
U - valued concrete field present in all instances of class T . 
An abstract field declaration has the form 

spec var a:T -> U 

where T is an object type and U is a type. This introduces two names: the name 
a for a U -valued abstract field present in all instances of class T , and the name 
res.a for a typeless field present in all instances of class T . The field res.a is 
called an individual residue variable, as described in Section 6.3. 

There is also a predeclared typeless field sres present in all object instances. 
This field is called the shared residue variable, as described in Section 6.3. 

Our only dependency declaration under consideration is a static dependency 
of the form 

depends a[t: T] on f[t] 

where a is an abstract field, / is either an abstract field other than a or a concrete 
field, T is an object type, and t is a dummy. Given such a declaration, we say 
that / is a direct dependency of a . 
A rep declaration has the form 

rep a[t: T] = e 

where a is an abstract field, e is an expression whose value is represented by a 
as described in Section 3, T is an object type, and t is a dummy whose scope is 
e . The only fields that may occur in e are direct dependencies of a , and each 
such occurrence must be indexed by the dummy t . The only free scalar variable 
in e is t. 

A method specification declaration has the form 

method m(t: T) requires p modifies w ensures q 

where p and q are expressions, w is a modifies list, T is an object type, and t 
is a formal parameter that can be used in p , w, and q . This declaration intro- 
duces the name m for a method with the given signature and specification. For 
simplicity, we consider only methods with one parameter (the so-called self pa- 
rameter); result values and additional parameters can be passed via the fields of 
the self parameter (cf. [0, 1,31]). 

A method implementation declaration has the form 

impl m(t: U) is C end 
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where m names a method, C is a command, U is an object type, and t is the 
name of the formal parameter as introduced in the declaration of m . The param- 
eter t can be used in C , but C may not assign to t . 

Actual programming languages would place further restrictions on the decla- 
rations above, including requirements of well-typedness and non-overlapping rep 
declarations (see, for example, Section 3). For the purposes of this appendix, how- 
ever, we consider a more general input, independently of such further restrictions. 

We assume that all names introduced are unique. So where actual program- 
ming languages may use scope rules to resolve certain names, we assume that all 
names are always fully qualified. 

Al Scopes 

For a set of declarations D , we write x e D to denote that x is an abstract field, 
concrete field, or individual residue variable declared in D , or that x is sres . For 
fields or residue variables x and y and a set of declarations D , we write x on D y 
to denote that x is abstract and y is res.x or sres , or that D contains a direct 
dependency of i on j. We write on^ for the reflexive, transitive closure of 
on D 

A set of declarations D is closed when every name mentioned in D also has a 
declaration in D . A set of declarations D is cycle-free when there are no distinct 
names x and y in D such that x on^ y A y on* D x . 

A scope is a (finite and) closed, cycle-free set of declarations. In an actual 
programming language, a scope would be determined by the units and the import 
relation among units (see Section 3). However, for the purposes of this appendix, 
defining scopes by units and imports is over-specific. Therefore, we require sim- 
ply that the underlying language have some way of specifying scopes and that 
each scope is a closed, cycle-free set of declarations. 

A2 User expressions 

Rep, method specification, and method implementation declarations contain com- 
mands and expressions. We call these expressions user expressions, in contrast to 
the expressions of verification conditions that will be described in Part II. We will 
give grammars for commands and user expressions, starting in this section with 
the grammar for user expressions. 
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We use e D to denote a user expression that can be written in a scope D . The 
shape of e D is defined by the following grammar: 



e D ::= s scalar variable 

| f[e D ] select 

| e D op e D any operator other than select 

| (Vs :: e D ) quantified expression 



A scalar variable is a parameter, local variable, or quantified scalar variable. 
A scalar variable is local to the enclosing declaration, command, or expression. 

In the select expression f[e D ] , / is a field in D (not a residue variable) and / 
is an adornment of / . Three kinds of adornments may be used in user expressions: 
the default (empty) adornment / , the pre-adornment / , and the post-adornment 
/ . Pre- and post- adornments are allowed only in ensures clauses, where they 
are used to denote the values of fields in the pre- and post-states of the method, 
respectively. The default adornment is used everywhere else and may not be used 
in ensures clauses. In this appendix, we write / and / to denote arbitrary adorn- 
ments of / . 

From the point of view of the meaning of an adorned variable, the adornment 
can be thought of simply as part of the name of the variable. But in the syntactic 
transformations occurring in verification condition generation and in our proof, it 
will be necessary to systematically change adornments within a formula. 

We call the second argument of a select expression an index expression. 

Here and throughout, we denote an arbitrary operator by the binary opera- 
tor op . Extensions to operators of other arities (including nullary operators) will 
always be straightforward and obvious; we omit them for brevity. We have distin- 
guished between select and other operators in the grammar for user expressions 
because fields in user expressions are allowed to occur only as first arguments to 
select. Other than that, select is really just another operator. 

The scope of the scalar variable s introduced by the quantified expression is 
bracketed by ( and ) . 

Note that residue variables cannot be mentioned explicitly in user expressions. 

We say "e is a user expression in D" to mean that e is generated by the 
grammar for e D . 
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A3 Modifies lists 



The modifies clause of a method specification declaration lists the designators 
that the method is allowed to modify. We call this list a modifies list. 

We use w D to denote a modifies list that can be written in a scope D . The 
shape of w D is defined by the following grammar: 

w D ::= list of f[e D ] designator expressions 

where in each designator expression f[e D ] , f is any field in D and all scalar 
variables in e D axe parameters (in particular, the self parameter of the method 
being specified, since that's the only parameter we allow in our simple notation). 

The index expression of each designator expression is interpreted as being 
evaluated in the pre-state of the method (cf. Section 7.2 under "Swinging pivots 
requirement"). 

We say "w is a modifies list in D " to mean that w is generated by the gram- 
mar for w D . 



A4 Commands 



We use C D to denote a command that can be written in a scope D . The shape of 
C D is defined by the following grammar: 



-d s '■— e D 

c[e D ] := e D 
assert e D 
assume e D 

Cd ; Cd 

C D D C D 
var s in C D end 
call m(e D ) 



simple assignment (to local variable) 
field update 



sequential composition 
choice composition 
local variable introduction 
method call 



Simple assignment is used to update the values of local variables. (There is no 
command to update the values of formal parameters once they have been bound 
through a method call.) The field update command c[eO] := e\ sets the concrete 
field c of object eO to el . There is no command to directly update abstract fields 
(or residue variables for that matter). Changing the value of a concrete field may 
cause a change in the values of abstract fields that depend on the concrete field. 
Residue variables cannot be modified by assignment commands. 
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The command assert e has no effect on the state if e holds, and causes the 
computation to go wrong if e does not hold. The command assume e also has no 
effect on the state, but can be started only in states that satisfy e . Further descrip- 
tion of these commands (other than their formal semantics, which is given below) 
is beyond the scope of this note (but see, for example, Nelson's Generalization of 
Dijkstra's calculus [43]). 

Command CO ; CI executes CO , then CI . Command CO D CI executes 
either CO or CI , blindly choosing which one. Command var s in C end intro- 
duces for use in C new local variable s , with an arbitrary initial value. Finally, 
call m(e) invokes method m with e as the actual self parameter. 

Other commands, such as a new command that allocates a new object, can be 
modeled as predefined methods or written in terms of the given commands. 

We say " C is a command in D " to mean that C is generated by the grammar 
for C D . 

Part II 

Verification condition generation 

A5 Verification conditions 

Each method implementation gives rise to a verification condition, a logical for- 
mula that is valid if and only if the method implementation is correct with respect 
to the specification; that is, started in a state satisfying the precondition, no exe- 
cution of the implementation goes wrong, and every terminating execution ends 
in a state that satisfies the postcondition, having modified only those designators 
permitted by the modifies list. 

Since we are interested in modular verification, the verification condition gen- 
eration is a function of the scope. For a method implementation C of a method m 
in a scope D , we write VC D (m, C) to denote the verification condition generated 
in D for C. 

If m is declared with the specification 

requires p modifies w ensures q 
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we define VC D (m, C) as 



BP D A Rep D A PW D A F D (p) 

(V£z :: zz = zz =3> (18) 
wlp D (C, (Vzz :: zz = zz =>■ FoO?) A mc D (w) )) ) 

where BP D is the background predicate generated in D , Rep D denotes the rep 
axioms of D , PW D denotes the pointwise axioms of D , F D is the meta function 
that functionalizes a user expression in D, zz is the list of concrete fields and 
residue variables in D , zz and zz are the list zz but with each field and residue 
variable pre-adorned and post- adorned, respectively, wlpo is the meta function 
that gives the semantics of a command in D , and mc D is the meta function that 
generates a modification constraint in D . All of these things will be defined in 
the next several sections. 

For any lists of variables xx and yy of equal lengths (such as zz and zz in 
(18)), we write xx = yy as a shorthand for X{ = y\ A x 2 = yi A ... A x N = y N 
where the x t 's and y t 's are the variables of the two respective lists. 

A remark about the second line of the definition of VC D is in order. This line 
essentially expresses the weakest precondition of command C with respect to the 
postcondition F D (q) A mc D (w) , that is, the postcondition contributions from the 
ensures clause and modifies clause, respectively. However, as we shall see from 
their definitions, the expressions F D (q) and mc D (w) are predicates on the pre- 
adorned and post-adorned fields, whereas the wlp D works on the default-adorned 
fields of its second argument. For any predicate Q , the expression 

( Vzz :: zz = zz =>• Q ) 

effectively changes the coordinates of Q : it says about zz whatever Q says about 
zz . This change of coordinates can equivalently be written as a substitution 

Q{zz := zz) 

This explains the shape of the second argument to wlpo in the definition of VCd ■ 
The quantification around the wlp D , which is really also a substitution, serves 
the purpose of identifying the pre-adorned fields of the wlp D expression with the 
default-adorned fields of the initial state. 

In Section A12, we give a grammar that generates the kinds of expressions 
that the meta expression VC D (m, C) produces. To distinguish these expressions 
from user expressions, we'll call them vanilla expressions. 
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A6 Functionalization 



For any scope D , we define a meta function F D thatfunctionalizes user expres- 
sions in D , that is, that turns each occurrence of an abstract field a into an appli- 
cation of the abstraction function named T.a to a 's dependencies, as described 
in Section 5.0. Meta function F D is defined inductively over the syntactic struc- 
ture of user expressions, and for convenience we also define F D on fields and 
residue variables: 

F D (s) = s scalar variable 



In these equations, the line for select is identical to the line for op , but we list 
it separately anyway. In the line for F D (a) , we have shown the definition for 
when a is an abstract field with exactly one direct dependency, / , in D . More 
general forms of this line are straightforward extensions. For example, if a has 
no dependencies in D , we have 

F D (a) = T.a{sres, res.a) 

and if a has two direct dependencies, fO and /l , in D , we have 

F D (a) = T.a{sres, res.a, F D (fO), F D (fl)) 

Throughout this appendix, we will usually show only the case for one direct de- 
pendency. 

In ordering the arguments to an abstraction function, any order (for example, 
alphabetical order) can be used as long as it is used consistently. 

Note, by the way, that the definition of F D is well-founded — that is, its recur- 
sive applications will eventually terminate — since D is a scope, which is (finite 
and) cycle-free. 

Finally, note that F D is really just a substitution: it substitutes a function 
application for each abstract variable. Consequently, 

F D is monotonic (19) 

that is, for boolean user expressions eO and el , if eO =>■ el is universally true, 
then so is F D (eO) =>• F D (el) . 



F D (f[e]) 

F D (c) 

F D (a) 



F D (f)[F D (e)] select 



c concrete field 

T.aisres, res.a, F D (f)) abstract field 

F D (eO) op F D (e 1 ) other operators 

(Vs :: F D (e) } quantified expressions 

r residue variable 



F D (e0o\tel) 

F D ((Vs :: e)) 
F D {r) 
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A7 Modification constraints 



For any scope D and modifies list w in D,we define mc D (w) , the modification 
constraint according to w in D , as follows: 

mc D (w) = ( /\ x | x e D :: modcon D (w, x, x) ) 

where modcon D (w, x, x) states that the variable x is not modified except as al- 
lowed by w . Before we give the formal definition of modcon D , we introduce two 
new pieces of notation. 

First, here and throughout, we use f\ and \J to denote meta-level quantifiers, 
that is, macros that generate expressions. The meta-level expression 

(A* I m :: S(x)) 

generates a conjunction with a conjunct S(x) for every x that satisfies R(x) , and 
similar for V -quantifications which generate disjunctions. Another meta-level 
expression is set construction. It is written 

{x | R(x) :: S(x) } 

and denotes the set with an element S(x) for every x that satisfies R(x) . 

Second, recall that our overall proof strategy is to transform the small-scope 
VC into a large-scope VC that is equally valid. To perform this syntactic trans- 
formation, we find it necessary to introduce syntactic markers into the VC as it 
is constructed. These markers have no semantic significance, but will be used in 
our proof. To introduce them, we use the syntax m:P to denote the expression P 
labeled with the marker m . 

Now for the definition of modcon D and some auxiliary meta functions. 

For any scope D and modifies list w in D, cl D {w) denotes the static closure 
of w in D and is defined as the set 

{/, e, x | f[e] e w a / on* D x :: x[e] } (20) 

A property of cl D that we will use later is that for any abstract variable a , user 
expression e , and modifies list w in D, 

a[e] e clo(w) = res.a[e] e clo(w) (21) 

(Proof: since a on D res.a , both sides of (21) are equivalent to the existence of a 
term f[e] in w such that / on^ a .) 
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For any scope D , field or residue variable y in D , modifies list w in D, and 
dummy variable s , the predicate modpointoiy, w, s) states that s is a modifica- 
tion point of y according to w . We define it as follows: 

modpointoiy, w,s) = ( V e | e c/d(w) :: s = e ) (22) 

where e ranges over user expressions and where we have written e to denote e 
in which all fields have been pre-adorned. The reason for this pre-adornment is 
mentioned in Section 7.2 under "Swinging pivots restriction". 

A consequence of the definition of modpoint and the cl property (21) is: for 
any modifies list w and abstract field a in a scope D , and any dummy s , 

modpoint D (a, w, s) = modpointoires.a, w, s) (23) 

Let D be any scope and w be any modifies list in D . Then, for any fields or 
residue variables x and y in D , the predicate modcon D (w, x, y) states that x is 
unchanged except possibly at the modification points of y according to w . We 
define it as follows: 

modcon D (w,x,y) = 

w:(V5 :: F D Qc[s] = x[s] v modpoint o(y,w, s)) } 

where s is a fresh dummy. The "w" in front of the quantification is a syntactic 
marker without semantic meaning. The predicate is usually used with the second 
and third arguments being equal, but we will use the extra generality in our proof. 



A8 Weakest liberal preconditions 

The semantics of commands is defined using weakest liberal preconditions. For 
any scope D , command C in D , and vanilla expression Q in D that contains no 
free occurrences of post-adorned fields or residue variables, the vanilla expression 
wlp D (C, Q) characterizes those pre-states ps of C such that 

• no execution of C from ps goes wrong, and 

• every terminating execution of C from ps ends in a post-state that satisfies 

Q. 
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Meta function wlp D is defined inductively over the syntactic structure of com- 
mands: 

wlp D (s:=e, Q) = (Vs' :: s' = F D (e) => 

(Vs :: s = s' => 2)} 

w/p D (c[<?0] := el, 0 = (Vc' :: c' = 5tore(c, F D (eO), F D (el)) => 

(Vc :: c = c' => Q » 

wlp D (assert e, 0 = F D (e) A 2 

(assume e, 0 = F D (e) =>• 2 

wlpo(C0 ; CI, 0 = w/p D (C0, w/MCl, 0) 

w/^(C0 D CI, 0 = w/pdCOO, 0 A w/^dCCI, 0 

w/p D (var 5 in C end, 0 = (Vs :: wlp D (C, 0} 

In the first two lines, s' and c' are fresh dummies. In the second line, store 
is the function associated with the select function [36] (see also axiom (43) in 
Section A22). The last of these lines requires that s not occur free in Q . Finally, 
for any method m whose specification, after renaming its parameter to a fresh 
dummy t , is 

method m(t: T) requires p modifies w ensures q 

we define 

wlp D (ca\lm(e), Q) = 
(V? :: t = F D (e) => 
F D (p) A 

(Viz :: zz = zz =>■ (V£z :: zz = zz =>■ 
(Vzz :: F/)(<5r) A mc D (w) =>• 

(Viz :: zz = zz =>■ (Vzz :: zz = zz =>■ 2 }}}}}} 

where zz is the list of concrete fields and residue variables in D , and zz denotes 
fresh adornments of zz . The reason for introducing zz is to effectively avoid vari- 
able capture of zz in Q (which may be easier to see in the equivalent formulation 
with substitutions, next). 

In the definition of wlpo , the quantifications occurring in the simple assign- 
ment, field update, and method call commands can also be written as substitutions. 
The wlp D of these commands are thus equivalently written as 

wlp D (s := e, 0 = Q{s := F D (e)) 

wlp D (c[eO] := el, Q) = Q(c := store(c, F D (eO), F D (el))) 
w//? D (call m(e), Q) = 
(W :: t = F D (e) => 

F D (p) a (Vzz :: (F D (q) A mc D (w))(zz := zz) =>• Q(zz := zz) » 
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A9 Rep axioms 



For any scope D , we define Rep D as a conjunction with one conjunct for each 
rep declaration in D . For a rep declaration 

rep a[t: T] = e 

the corresponding conjunct, called a rep axiom, is 

( W: T, res.a,f :: t ^ nil =>• T.a{sres, res.a,f)[t] = e ) 

where we have shown the case where a has exactly one direct dependency, / , in 
D . 

Note that e is not functionalized, see Section 5.0. 

This is the only place in our verification condition generation where we make 
use of types: we retain the type of the dummy t in the rep axiom. (This is not 
important for the soundness of modular verification, but it is important in order 
to generate a desirable verification condition. In particular, this avoids logical 
inconsistencies resulting from inconsistent rep axioms.) 



A 10 Pointwise axioms 

Because occurrences of dependencies of a in a rep declaration for a[t: T] are 
indexed by t , it follows that the abstract value of a[t] does not change if a 's de- 
pendencies change only at objects other than t . But our functionalization, which 
transforms a[t] into an expression like !F.a{sres, res.a,f)[t] , seems to lose this 
fact. To compensate, we supply an explicit pointwise axiom for each abstraction 
function, see Section 5.0. 

For any scope D , we define PW D as a conjunction with one conjunct for 
each abstract field in D . For an abstract field a , the corresponding conjunct is 
the pointwise axiom for T.a : 

(V 't, sres, sres, res.a, res.a,} ',/ :: 

sres[t] = sres[t] A res.a[t] = res.a[t] A f[t] =f[t] n c\ 

F.a{sres, res.a, f)[t] = T.aisres, res.a, f)[t] } 

where t is a fresh dummy, and where we have shown the case where a has exactly 
one direct dependency, / , in D . 
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All Background predicate 



Each scope gives rise to a background predicate, which is a conjunction of ax- 
ioms that formalize various properties of the type system. For any scope D , we 
use BP D to denote the background predicate produced in D . The exact axioms 
placed in the background predicate are not relevant to this appendix, but we do 
assume that the set of axioms produced grows monotonically with the set of type 
declarations in a scope. That is, let BPS D denote the set of background-predicate 
conjuncts produced for a scope D so that 

BPd = (AQ I Q<=BPS D :: Q) 

and let Types(D) denote the set of type declarations in D ; then we assume BPS 
to have the following property, for any scopes D and E : 

Types (D) c Types(E) => BPS D c BPS E 

Consequently, we have 

D c E => [BP D BP E ] (26) 

Note that if Types(D) = Types(E) , then BPS D = BPS E ■ Thus, a consequence of 
our assumption about the background predicate is that BP D does not depend on 
the field declarations in D . 



A 12 Vanilla expressions 

Now that we have defined all of VC D (m, C) , we can describe the shape of the 
resulting expressions. Such a description will come in handy in Part III of this 
appendix. We define a vanilla expression to be an expression that is generated by 
the grammar below and satisfies characteristics VO through V5, listed below. We 
claim that any expression generated by VC D (m, C) is a vanilla expression. 

Using Q D to denote a typical vanilla expression in a scope D , the grammar 
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is: 

Qd "= 

s scalar variable 

| c concrete field 

| T.aisres, res.a, Qd) abstraction function 

I Qd op Qd operator, possibly select or store 

| (Vs :: Q D ) quantification over scalar 

| (Vx :: Q D ) quantification over concrete field or 

residue variable 

| (Vr :: r = r =)• Q D ) quantification over residue variable, 

with equality antecedent 

| w D :(Vs :: r[s] = f[s] v Q D ) residue modification constraint 

| see formula (25), page 84 pointwise axiom 

| (V t:T,sres, res.a, f :: t nil =>• T.a{sres, res. a, f)[t]= e D ) 

rep axiom 

As usual, we have shown only the cases where an abstract variable has exactly 
one dependency in D ; extensions to other numbers of dependencies are straight- 
forward and obvious. We have treated expressions with markers, like w.Q, as 
unary expressions where the "w:" is the operator, except in the case of residue 
modification constraints, whose inside of the quantified formula is otherwise not 
a vanilla expression. 

The definition of VC D seems not to fit this grammar, because it produces 
quantified expressions that quantify over all concrete fields and residue variables 
in D . For example, visible directly in the definition of VC D , (18) on page 79, is 
a subexpression of the form 

(V£z :: zz = zz => Q) (27) 

where zz is the list of all concrete fields and residue variables in D . To fit the 
grammar for vanilla expressions, we must think of expression (27) as the seman- 
tically equivalent expression 

(Vci :: ci = ci =>• (Vc 2 :: c 2 = c 2 =>■ ••• (Vc^ :: c N = c N =>• 
( V sres : : sres = sres 

(Vr, :: r 1 = n => ■■■ (Vr* :: r> = r„ ^ Q )•••)))••• )} 

where the c ; 's denote the concrete fields in D and the r, 's denote the individual 
residue variables in D . A similar remark applies to the other quantification in 
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(18) and the quantifications in the definition of wlp D for a method call. We will 
treat the two representations interchangeably and refer to the quantifications as 
forming a cluster. 

We say the bound variables (adorned concrete fields and residue variables) of 
one cluster belong to the same generation. Variables of the same generation have 
the same adornments, but variables with the same adornments are not necessarily 
of the same generation. 

The formulas generated by VC D have more characteristics than are expressed 
by the grammar. We note the following characteristics of formulas generated by 
VC D (m,C): 

VO. Pointwise axioms and rep axioms occur only in negative positions. 

VI. For any concrete field or residue variable x , quantifications over x , with and 
without equality antecedents (more precisely, the quantifications occurring 
in the sixth and seventh lines of the grammar of Q D ), occur only in positive 
positions. 

V2. For any concrete field or residue variable x , if there is no field update com- 
mand of x in C , then any quantification over x, , with or without equal- 
ity antecedent, appears in VC D (m, C) in a cluster of quantifications (with 
or without equality antecedents, respectively) over all the variables in zz , 
where zz is the list of concrete fields and residue variables in D . 

V3. Modification constraints, and in particular shared-residue modification con- 
straints, are generated only by the modcon meta function. Thus, a residue 
modification constraint 

w:{Vs :: sfes[s] = sres[s] v Q ) (28) 
occurring in VC D (m, C) has the form dictated by 

modcon D (w, sres, sres) 
In other words, the Q in (28) necessarily has the form 

F D (modpointD(sres , w, s)) 
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V4. Each occurrence of an abstraction function T.a is generated either by the 
meta function F D or as part of a pointwise axiom or rep axiom. By inspect- 
ing these definitions, one finds that the arguments to T.a are sres , res.a , 
and the direct dependencies of a , all adorned in the same way. 

V5. For any subexpression Q in VCo(m, C) that does not break any cluster of 
quantifications (that is, Q does not contain part of a cluster without con- 
taining all of it), the free occurrences in Q of concrete fields and residue 
variables with the same adornments belong to the same generation, except 
possibly for those concrete fields for which C contains a field update com- 
mand. Consequently, and using V4, the arguments of any given application 
of an abstraction function T.a are all of the same generation, except pos- 
sibly those concrete- field arguments for which C contains a field update 
command. 

We define a vanilla expression to be any expression generated by the grammar 
above and satisfying the characteristics VO through V5. 

So much for verification condition generation. 

Part III 

Modular soundness 

A 13 The theorem of soundness of modular verifica- 
tion 

Soundness of modular verification is what justifies that one can prove the cor- 
rectness of a method implementation without needing the entire program. This 
is important because it allows modules to be proved separately, without a need to 
re-prove them as they are linked together. Our theorem of soundness of modu- 
lar verification states that to prove the VC generated in a larger scope for some 
method implementation, it suffices to prove the VC generated in a smaller scope 
for that method implementation. 

We use the notation [P] (pronounced "everywhere P") to say that a formula 
P is true in all infinite models. Since the theory with respect to which we verify 
programs includes the integers, of which there are infinitely many, " [P] " is for 
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our purposes as good as saying that "P is valid", that is, that P is semantically 
equivalent to true [10]. Nevertheless, for technical reasons that we will describe 
later, we must define our "everywhere brackets" to ignore finite models. Our 
everywhere brackets satisfy [P] = [(Vx :: P }] for x an individual variable or 
function symbol, and therefore we may think of them as universally quantifying 
all free variables and function symbols over some infinite domain. 

Equipped with everywhere brackets, we can now state our soundness theorem. 
As discussed in Section 6, the property 

D C E A [VC D (m, Q] => [VC E (m, Q] 

where D and E are scopes containing an implementation C for a method m , 
does not hold for all scopes D and E . This discussion then led us to the intro- 
duction of the visibility and top-down requirements for static dependencies. Here, 
we formalize those requirements as a relation on two scopes D and E , where 
D c E: 

Vis(D,E) = (Vx, y :: x € D A y € D A xon E y =>• x on D y } 

TopDown(D, E) = (Vx, y :: yeD A xon E y 4 xeD) 

The theorem of soundness of modular verification is: 

Soundness Theorem. For any scopes D and E , containing an implementation 
C for a method m , 

D c £ A Vzs(D, £) A TopDown(D, E) A [VC D (m, Q] [VC E (m, Q] 

The theorem essentially states that VC generation is monotonic with respect 
to scope. 

Note that the theorem is not about the soundness of the VC generation with 
respect to some operational semantics of the command language. In fact, the 
theorem says nothing about the utility of the meta functions VC D and VC E — 
for all we know, these meta functions might generate formulas that are totally 
irrelevant to any question of program correctness. Our theorem simply states that 
if the VC generated by VC D is valid, then so is the VC generated by VC E . 

But of course we do claim that the theorem is useful, because we claim, with- 
out proof, that VC E generates a VC that is appropriate for an entire program E , 
modulo the issues discussed in Part IV of this appendix. 
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A 14 Proof strategy 



The soundness theorem states that if the modularity requirements are respected, 
then adding declarations to a scope does not invalidate method implementations 
in the scope. For some kinds of added declarations, the proof is quite easy; for 
others, it is harder. We begin with two lemmas (Soundness Lemmas A and B, 
in Section A15) that handle all the easy cases (namely: additional type declara- 
tions, rep declarations, method declarations, and method implementation decla- 
rations). We then proceed to the difficult case, which is where the added decla- 
rations consist of a new field together with some number of dependencies on the 
field. Soundness Lemma C (Section A16) applies to this case if the new field is 
concrete, and Soundness Lemma D (also in Section A16) applies if the new field 
is abstract. The proof of Soundness Lemma D relies on Soundness Lemma C, so 
the heart of the soundness proof is Soundness Lemma C. Soundness Lemma E 
(Section A 16) combines Soundness Lemmas C and D in a straightforward way. 
Soundness Lemma F (Section A17) uses induction and Soundness Lemma E to 
prove the soundness of extensions by multiple fields. Finally, Section A18 shows 
that these soundness lemmas add up to a proof of the Soundness Theorem. 

In Section A 16, we state Soundness Lemma C and sketch an informal argu- 
ment for its correctness, but the formal proof (Sections A19-A32) is deferred for 
the convenience of any readers who may prefer to skim it. 

Our journey will be long. To make it as readable as possible, we make heavy 
use of the calculational proof format suggested by WimH. J. Feijen [10]. We hope 
its explicit hints will make each of the numerous little proof steps manageable to 
check. 

A 15 Type, rep, and method declaration discrepan- 
cies 

In this section and the next two, we consider specializations of the Soundness The- 
orem. We start in this section by stating and proving two lemmas. The first lemma 
considers scopes D and E that differ only in their type declarations. The second 
lemma considers scopes that differ only in their rep and method declarations. 

Soundness Lemma A. For any scopes D and E , containing an implementation 
C for a method m , if D and E differ only in their type declarations (that is, if 
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the sets D and E minus their type declarations are equal), then 

D c £ A Vzs(D, £) A TopDown(D, E) A [VC D (m, Q] => [VC E (m, Q] 

/Voo/ Let zz denote the list of concrete fields and residue variables in D , and 
suppose the specification of m is 

requires p modifies w ensures q 

We then calculate, 

[VC D (m, Q] 
{ VC D } 

[BP D A Rep D A PW D A F D (p) => (V£z :: £z = zz => 
wlp D {C, (Vzz :: zz = zz =>■ ^d^) a mc D (w) )) }] 
=> { by DC£ and (26), we have [BP D <^ } 

[BP E A Rep D A PW D A F D (p) => (Vzz :: zz = zz => 
wlp D (C, (Vzz :: zz = zz =>■ F D (^) A mcoCw) )) }] 
= { D and E are equal except for their type declarations, so 

Rep E = Rep D , PW E = PW D , F E = F D , = w/p D , and 
mc E = mc D } 
[BP E A Rep E A PW E A F E (p) => (Viz :: zz = zz => 
wlp E {C, (Vzz :: zz = zz =>• i 7 ^^) A mc £ (w) }) }] 
= { VC £ , since zz is the list of concrete fields and residue variables 

in E } 

[VC E (m, Q] □ 

Soundness Lemma B. For any scopes D and E , containing an implementation 
C for a method m , if D and E differ only in their rep, method specification, and 
method implementation declarations, then 

D c £ A Vzs(D, £) A TopDown(D, E) A [VC D (m, C)] => [VC E (m, Q] 

Proo/ Let zz denote the list of concrete fields and residue variables in Z) (hence 
also in £), and suppose the specification of m is 

requires p modifies w ensures q 

We calculate, 
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[VC D (m, Q] 
{ VC D } 

[BP D A Rep D A PW D A F D (p) => (Vzz :: zz = zz => 
wlp D (C, (Vzz :: zz = zz =>• F^O?) A mc D (w) }) }] 
=> { by DC£ and (26), we have <^= BP E ] } 

[BP E A Rep D A PW D A F D (p) => (Vzz :: zz = zz => 
wlp D (C, (Vzz :: zz = iz => F D (q) A mc D (w) )) }] 
=>■ { by Z) c £ , the fact that D and £ coincide in their field and 

dependency declarations, and the definition of rep axioms, we 
have [Rep E =>• Rep D ] } 
[BP E A Rep E A PW D a F D (p) => (Vzz :: zz = zz => 
wlp D (C, (Vzz :: zz = zz => F D {q) A mc D (w) }) }] 
= { D and £ are equal except for their rep, method specification, 

and method implementation declarations, so PW D = PW E , 
Fd = F E , wlp D = wlp E , and mc D = mc E } 
[BP E A Rep E A PW E a F E (p) => (Vzz :: zz = zz => 
wlp E (C, (Vzz :: zz = 7Z =>■ a mc £ (w) )) }] 

= { VC £ , since zz is the list of concrete fields and residue variables 

in £ } 
[VC £ (m, Q] 



A 16 Single field-declaration discrepancies 

In this section, we state three lemmas as specializations of the Soundness Theo- 
rem. We prove the second and third, but defer the proof of the first lemma until 
Section A19 and beyond. 

We define a property Extend . For any D , e , and E , Extend(D, e, E) says 
that D and E are scopes that differ only in that E additionally contains the 
declaration of a concrete field e and some number of dependencies on s . Note 
that 

ExtendiD, s, E) => D c £ A Vzs(D, £) A TopDown(D, E) 

Here's the first of the three lemmas of this section, a lemma that captures the 
essence of the Soundness Theorem. 
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Soundness Lemma C. For any scopes D and E , containing an implementation 
C for a method m , and any concrete field s , 

Extend(D,s,E) A [VC D (m, Q] => [VC E (m, Q] 

The formal proof of Soundness Lemma C is presented in Sections A19 through 
A32. In the meantime, here is an informal sketch of an argument for the correct- 
ness of the lemma. 

Proof sketch. Given Extend(D, s, E) and that VC D (m,C) is valid, we must prove 
that VC E (m, C) is also valid. There are two differences between VC D (m, C) and 
VC E (m, C) . 

The first difference is that, for any abstract variable a that depends on e (in 
E ), occurrences of a are functionalized differently in D and in E . Wherever we 
have in D a subexpression like T.a(sres, . . .) , we have instead in E a subexpres- 
sion like T.a(sres, . . . , e) . 

The second and more difficult difference is that modifies lists are desugared 
differently in D and in E : the modification constraints in E mention e , but the 
corresponding modification constraints in D do not mention s . 

The first difference is resolved using shared residues: the universal validity 
of the formula VC D (m, C) implies the validity of (V sres :: VC D (m,C) }, 
which means that for the D -scope sres we can substitute the ordered pair of 
s and the E -scope sres . Thus by a validity-preserving transformation, the D- 
subexpression T.aisres, . . .) becomes T.a{{sres, e), . . .) . The universal validity 
also allows us to substitute any function for the uninterpreted function T.a . So for 
the D -scope T.a we can then substitute a function that picks apart the ordered 
pair and applies the E -scope T.a to sres, s , and any other arguments, which 
is exactly the E -scope expression to which occurrences of a are functionalized. 
Thus by composing these two validity-preserving transformations, the differences 
between VC D and VC E due to differently functionalized abstract variables disap- 
pear. 

The second difference is resolved using individual residues: Since m 's imple- 
mentation C contains no occurrences of e , we must prove that m 's modification 
constraint for e follows from the various modification constraints for e arising 
for each method call in C . For any abstract variable a , the VC in the small scope 
asserts that m 's modification constraint for res.a follows from the various mod- 
ification constraints for res.a arising for each method call in C , because there 
are no occurrences of residue variables in C . Since the modification points of s 
equals the union of the modification points of the abstract variables that depend on 
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s , which coincides with the modification points of the residues of those variables, 
the small-scope proof for the residues implies the large-scope proof for e . □ 

The next lemma is like Soundness Lemma C, except that e is abstract. We 
will not define another flavor of Extend for abstract fields, so the lemma repeats 
the relevant properties of Extend . 

Soundness Lemma D. Let D and E be scopes containing an implementation 
C for a method m . If D and E differ only in that E additionally contains the 
declaration of an abstract field s and some number of dependencies on e , then 

[VC D (m,Q] [VC E (m,Q] 

Proof. We prove the lemma by constructing two new scopes G and H , applying 
Soundness Lemma C to the pairs of scopes (D, G) and (G, H) , respectively, and 
then obtaining [VC E (m, C)] by massaging the formula [VC H (m, C)] . 

Let D and E satisfy the antecedent of the lemma, and let G be the set E but 
where E contains the declaration 

spec var e:T -> U 

G instead contains the declaration 

var s :T -> U 

We have that D and G now fit the description of D and E in the antecedent of 
Soundness Lemma C, from which we then conclude [VC G (m, C)] . 
Let H be the set G but where G contains the declaration 

var s: T -> U 
H additionally contains the declaration 

\ar8:T -> U 
and where G contains a declaration 

depends a[v: V] on e[v] 
for any a , v , and V , set H additionally contains the declaration 

depends a[v: V] on 8[v] 
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We have that G and H fit the description of D and E in the antecedent of 
Soundness Lemma C, from which we conclude [VC//(m, C)] . 

Let us now consider how the formula VC H (m, C) differs in structure from the 
formula VC E (m, C) , so that we can take validity-preserving steps to reconcile the 
differences. 

Let zz denote the concrete fields and residue variables in D , and suppose the 
specification of m is 

requires p modifies w ensures q 

Then VC H (m, C) is the expression 

BP H A Rep H A PW H A F H (p) => 

(Viz, £, 8::zz = zzas = saS = S =>• 

wlp H (C, ( V 'zz, e, 8 :: zz = zz a e = e A 8 = 8 =>• 
F H (q) A mc H (w) }) ) 

Scope H contains the concrete fields s and 8 , whereas scope E contains the 
abstract field e . Since the user expressions that play a part in the generation of 
the verification conditions VCnim, C) and VCsim, C) are all in the smaller scope 
D , there is no direct mention of e or 8 in the command C or in the specifications 
of the methods called from C . But s and 8 may still appear in VC H (m, C) and 
VC E (m, C) , as follows: 

• For every abstract variable a that depends on s in E , and thus on e and 8 
in H , the abstraction function T.a in H has arguments corresponding to 
both e and 8 , whereas the function T.a in E has an argument correspond- 
ing to e but not to 8 . The extra argument is found in all occurrences of T.a 
in VC H (m, C) , that is, in functionalized user expressions, in rep axioms for 
a , and in the pointwise axiom for T.a . 

• For every modifies list v , mc H {v) contains the conjuncts 

v:(V5 :: s[s] = s[s] v F H (modpoint H (e,v, s)) ) A 
v:(Vs :: 8[s] = 8[s] v F H (modpointH(S,v, s)) ) 

whereas mc E (v) instead contains the conjuncts 

v:( V s :: T.s(sres, s)[s] = Ts(sres, s)[s] v 

F E (modpoint E (s, v, s)) ) A 
v:(V5 :: res.s[s] = res.e[s] v F E (modpoint E (res.s,v, s)) ) 
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Note that since v does not directly mention s or 8 , and since an abstract 
field depends on s in H exactly when it also depends on <5 in H , we have 

(We :: s[e] € cl H (v) = 8[e] € cl H (v) } 

and hence modpoint H (s, v, s) = modpoint H (8, v, s) . Moreover, due to (23), 
we have modpoint E {s, v, s) = modpointE(res.e, v, s) . Finally, since an ab- 
stract field depends on s in H exactly when it depends on s in E , we 
have 

(We :: s[e] e cl H (y) = e[e] e cl E (v) ) 

and hence modpointn(s, v, s) = modpoint E (s, v, s) . Thus, the expansions 
of the four modpoint expressions above are the same. Their functionaliza- 
tions differ as described in the previous bullet. 

• Since s is abstract in E, VCE(m,C) contains a pointwise axiom for T.e . 
There is no such axiom in VC H {m, C) . 

• Where the verification conditions contain quantifications over all concrete 
fields and residue variables, with or without equality antecedents, the quan- 
tifications in VC H (m, C) are over e and 8 , possibly with the equality an- 
tecedent e = e A 8 = 8, whereas the quantifications in VC E (m, C) are 
over res.s , with the respective antecedent res.s = res.s . 

The verification conditions VC H (m, C) and VC E (m, C) are vanilla expres- 
sions as defined by the grammar and characteristics VO through V5 in Section A12. 
Figure 1 1 classifies the differences between the two VCs according to the vanilla 
grammar. In particular, it shows all the ways that s , 8 , T.e , and res.s may oc- 
cur. Using characteristic V2 (page 87), the figure shows the quantifications over s 
and 8 together with the neighboring quantifications over sfes . Squinting at this 
formula, we see that variables s and 8 in VC H (m, C) play roles that are similar 
but not identical to T.e(sres, res.s) and res.s , respectively, in VC E {m,C). We 
will have to work on the differences. 

We are now starting the process of transforming VC H (m, C) into VC E (m, C) . 
We do so by a series of transformations to the working formula, which starts off 
as the formula VC H (m, C) and ends up as VC E (m, C) . Our series of transforma- 
tions are guided by the differences shown in Figure 1 1 . To help us keep track of 
the effect of the transformations applied so far, we will provide sketches of the 
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VC H (m, C) 



VC E (m, C) 



AO. Functionalized occurrences of abstract variables that depend on s: 

T.a(sfes, . . . , s, 8) T.a(sfes, . . . , T.s(sfes, res.s)) 

Al. Quantifications over concrete fields and residue variables: 

(Vsfes,8,s :: ...} (V sfes, res.s :: ...} 

A2. Quantifications over concrete fields and residue variables, 
with antecedents: 
(V sfes, 8, s :: (V sfes, res.s :: 

sfes = sfes A 8 = 8 A s = s sfes = sfes A res.s = res.s 
=>...} =>...) 
A3. Modification constraints of s: 

v:(V5 :: s[s] = s[s] v ...} v:(Vs :: F.s{sfes, re"s.s)[s] = 

T.s{sfes, res.s)[s] V . . . ) 

A4. Modification constraints of 8 and res.s: 

v:(Vs :: 8[s] = 8[s] v ...) v:(Vs :: res.s[s] = res.s[s] V ...) 

A5. Pointwise axiom for T.s: 

no pointwise axiom for T.s pointwise axiom for T.s 

A6. Pointwise axiom for T.a: 

includes 8 argument to T.a does not includes 8 argument to T.a 

Al. Rep axioms for a: 

includes 8 argument to T.a does not includes 8 argument to T.a 

Figure 11: An illustration of the syntactic differences between VC H (m, C) and 
VC E (m, C) . 



97 



AO: T.a(sfes, ...,£, 8) 
Al: {Vsfes,8,e :: ... } 

A2: ( V sfes, 8,s :: sras = sres A 8 = 8 A e = s =>• ...} 

A3: v:(Vs :: e[s] = e[j] v ... } 

A4: v:(Vs :: S[s] = 8[s] v ... > 

A5: no pointwise axiom for T.e 

A6: (V t, sres, sres, . . . , s, s, 8, 8 :: 

sres[t] = sres[t] A ... A e[t] = e[t] A 8[t] = 8[t] =>• 
T.aisfes, . . . , s, 8)[t] = T.a{sres, ...,£, 8)[t] ) 

A7: (Vt:T, sres, . . . , s,8 :: t ^ nil =>• T.a(sres, ...,£, 8)[t] = . . . } 

Figure 12: A sketch of the initial working formula, VC H (m, C) . 

working formula in Figures 12 through 16. Figure 12 contains our first sketch of 
the discrepancy formulas from the left column of Figure 11. 

(Alternatively, but more verbosely, instead of showing a sketch of each work- 
ing formula, we could give a grammar that describes the formula. Or even more 
verbosely, we could give the full recipe for generating the formula, more or less 
duplicating Part II for each working formula. We find our sketches to convey the 
essential information more concisely.) 

Step 0: From Figure 12 to Figure 13. In our first transformation of the work- 
ing formula, we replace T.a , for every a that depends on e , by a function that 
doesn't actually make use of the 8 argument. This transformation is justified by 
the fact that everywhere brackets quantify over function symbols like T.a : Let Q 
denote the current working formula. We consider the case where abstract variable 
a has exactly three dependencies, f,s, and 8 ; other cases are straightforward 
and omitted. We calculate, 

[Q] 

=> { instantiate the universally quantified T.a } 

[Q(T.a := ( ksres, res.a,f, s, 8 :: T.a(sres, res.a,f, s) })] 

After applying this calculation to the working formula for every a that directly 
depends on e and then applying jS-conversion (unfold) on the ^-expressions (that 
is, applying the A.-expressions to their arguments), the working formula will have 
the form sketched in Figure 13. 
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AO: T.aisres, ...,£) 
Al: (Vsfes,8,s :: ... } 

A2: (Vsfes, 8, s :: sres = sres A 8 = 8 A s = s =>• ...} 

A3: v:(Vs :: s[s] = e[s] v ... } 

A4: v:(Vs :: S[s] = 8[s] V ... } 

A5: no pointwise axiom for T.e 

A6: (V t, sres, sres, . . . , s, e, 8, 8 :: 

sres[t] = sres[t] A ... A e[t] = s[t] A 8[t] = 8[t] => 
J-'.aisres, . . . , s)[t] = T.aisres, . . . , e)[t] ) 

A7: (Vt.T, sres, . . ., s,8 :: t ^ nil =>• T.aisres, . . . , s)[t] = ...) 



Figure 13: A sketch of the working formula after substituting new functions T.a 
for those in Figure 12, which affects lines AO, A6, and A7. 

Step 1: From Figure 13 to Figure 14. It is now easy to tidy up any rep axioms 
for a and the pointwise axiom for T.a . Let's do each in turn. 

Consider a rep axiom for any a that depends on s . If a depends on / , s , and 
8 in H , the rep axiom has the following shape in the current working formula: 

(V f.T, sres, res.a,f, s, 8 :: t nil =>• T.a(sres, res.a,f, s)[t] = e } 

Since e is a user expression in D , it does not mention 8 . So the quantification 
over 8 can be dropped, producing the equivalent formula: 

(V f.T, sres, res.a,f, s :: t ^ nil =>• T.a(sres, res.a, f,s)[t] = e ) 

Cases where a has a different set of dependencies in H are similar and omitted. 

Similarly, for any a that depends on / , e , and 8 in H , we calculate from 
the pointwise axiom for T.a in the working formula, 

(V?, sres, sres, res.a, res.a, f,f, s, s, 8, 8 :: 
sres[t] = sres[t] A res.a[t] = res.a[t] A 

fm =M a m = m a kt] = m => 

T.a(sres, res.a, f, s)[t] = T.aisres, res.a, f, e)[t] ) 
•<= { weaken antecedent } 

(V?, sres, sres, res.a, res.a, f,f, s, s, 8, 8 :: 

sres[t] = sres[t] A res.a[t] = res.a[t] A f[t] =f[t] A s[t] = s[t] =>• 

T.aisres, res.a, f, s)[t] = T.aisres, res.a, f, s)[t] ) 
= {8 and 8 do not occur } 
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AO: T.aisfes, ...,£) 

Al: (V sfes, res.s, s :: ...} 

A2: (y sfes, res.s, s :: sfes = sfes A res.s = res.s A s = s =>• ...} 

A3: v:(Vs :: s[s] = s[s] v ... ) 

A4: v:(Vs :: res.s[s] = res.s[s] V ...) 

A5: no pointwise axiom for T.s 

A6: ( V t, sfes, sfes, . . . ,s,s :: 

sfes[t] = sfes[t] A ... A s[t] = s[t] =>• 
T.a(sfes, . . . , s)[t] = T.a(sfes, . . . , s)[t] ) 

A7: (Vt.T, sres, . . . , s :: t ^ nil =>• T.aisres, . . . , s)[t] = . . . ) 

Figure 14: A sketch of the working formula after tidying up the rep and pointwise 
axioms and renaming 8 to res.s , which affects Al, A2, A4, A6, and A7. 

(V?, sfes, sfes, res.a, res.a,f,f, s, s :: 

sfes[t] = sfes[t] A res.a[t] = res.a[t] A f[t] =f[t] A s[t] = s[t] =>• 
T.a{sfes, res.a, f, s)[t] = T.aisres, res.a, f, e)[t] ) 

Cases where a has a different set of dependencies in H are similar and omitted. 

Since pointwise axioms appear only in negative positions (see characteristic 
VO, page 87), applying these transformations to rep and pointwise axioms in the 
working formula sketched in Figure 13 preserves its validity. 

Having removed occurrences of 8 from rep and pointwise axioms, we now 
rename each remaining occurrence of 8 to res.a The resulting formula is shown 
in Figure 14. 

Step 2: From Figure 14 to Figure 15. We are now done with the transformation 
of 8 into res.s and so we turn to the transformation of s into T.sisres, res.s) . 
To this end, we first add the pointwise axiom for T.s . Since pointwise axioms 
occur in negative positions (by characteristic VO, page 87), this transformation 
weakens the working formula, preserving its validity. Next, we calculate for any 
predicate Q , possibly including equality antecedents, 

( V sfes, res.s, s :: Q) 
=>• { instantiate s := T.s(sfes, res.s) } 

(V sfes, res.s :: Q(s := T.s{sfes, res.s)) ) 
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AO: T.aisfes, . . . , T.eisfes, res.e)) 
Al: ( V sfes, res.e :: . . . } 

A2: (V sfes, res.e :: sfes = sfes A res.e = res.e A 

T.eisfes, res.e) = T.eisfes, res.e) =>• . . . } 

A3: v:(Vs :: T.eisfes, res. e)[s] = T.eisfes, res. e)[s] V ...) 

A4: v:(Vs :: res.e[s] = res.e[s] V ...) 

A5: (V?, sres, sres, res.e, res.e :: 

sr<?s[?] = sres!/] A res.e[t] = res.e[t] =>• 
Teisres, res.e)[t] = T.e(sfes, res.e)[t] ) 

A6: (V t, sres, sfes, ... ,e, e :: 

5re5[?] = .sres!/] A ... A = e[t] =>• 
T.a(sfes, . . . , e)[t] = T.a(sfes, . . . , e)[t] ) 

A7: {Vt:T, sres, . . ., e :: ? 7^ nil =>• T.aisres, . . . , e)[t] = . . . } 



Figure 15: A sketch of the working formula after introducing the pointwise axiom 
for T.e and instantiating the concrete e with the functionalized abstract e . These 
transformations affect AO, Al, A2, A3, and A5. 

Since such quantifications appear only in positive positions (by characteristic 
VI, page 87), applying this transformation to all quantifications, with or with- 
out equality antecedents, preserves the validity of the working formula. The re- 
sulting working formula is sketched in Figure 15. Because of characteristic V5 
(page 88), the arguments we have supplied to T.e are indeed the ones supplied to 
T.e in VC E (m, C) . 

Step 3: From Figure 15 to Figure 16. Almost there. Now we just need to get 
rid of the conjunct 

T.eisfes, res.e) = Teisfes, res.e) 

from quantifications with equality antecedents. We calculate, 

sfes = sfes A res.e = res.e A T.eisfes, res.e) = T.eisfes, res.e) 
= { third conjunct follows from the first two } 

sfes = sfes A res.e = res.e 

Applying this transformation to the working formula from Figure 15, we arrive 
at the formula sketched in Figure 16, which is exactly the formula VC E im, C) 
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AO: T.a(sfes, . . . , T.s(sfes, res.s)) 
Al: ( V sfes, res.s :: . . . } 

A2: (V sfes, res.s :: sfes = sfes A res.s = res.s =>• ...} 

A3: v:(Vs :: F.s (sfes, res. s)[s] = F.s (sfes, res. s)[s] V ...) 

A4: v:(Vs :: re"s.s[s] = res.s[s] V ...) 

A5: (y t, sfes, sfes, res.s, res.s :: 

sresl/] = sreslYI A res.£[/] = res.s[t] =>■ 
F.s(sfes, res.s)[t] = T.s(sfes, res.s)[t] ) 

A6: ( V t, sfes, sfes, . . . ,s, s :: 

sfes[t] = sfes[t] A ... A s[t] = s[t] =>■ 
J^.a(sfes, . . . , s)[t] = T.a(sfes, . . . , s)[t] ) 

A7: (Vt:T, sres, . . ., s :: t ^ nil =>• T.a(sres, . . . , s)[t] = ...}... 

Figure 16: A sketch of the final working formula, obtained from Figure 15 by 
applying the pointwise axiom for T.s , which affects A2. 

sketched in the right column of Figure 11. So in summary, we have transformed 
formula VC H (m, C) into formula VC E (m, C) by applying validity-preserving 
steps, thereby completing the proof of Soundness Lemma D. m 

The third lemma of this section is a simple corollary of the other two, allowing 
the field s to be either concrete or abstract. 

Soundness Lemma E. Let D and E be scopes containing an implementation 
C for a method m . If D and E differ only in that E additionally contains a 
declaration of a (concrete or abstract) field s and some number of dependencies 
on s , then 

[VC D (m,Q] [VC E (m,Q] 
Proof. Follows directly from Soundness Lemmas C and D. □ 

A 17 Multiple field-declaration discrepancies 

In this section, we present the last of the specializations of the Soundness Theo- 
rem. The specialization concerns scopes that differ only in their field and depen- 
dency declarations. We prove this specialization from Soundness Lemma E and 
induction. 



102 



Soundness Lemma F. For any scopes D and E , containing an implementation 
C for a method m , if D and E differ only in their field and dependency declara- 
tions, then 

D c E A Vis(D, E) A TopDown(D, E) A [VC D (m, Q] => [VC E (m, Q] 

Proof. Let D and £ be scopes satisfying the antecedent. Using Soundness 
Lemma E, we now prove the lemma by induction over the number of fields de- 
clared in E and not in D . We consider two cases. 

CASE D and E coincide in their field declarations: Due to Vis(D, E) , we have 
that D and E coincide also in their dependency declarations. Hence, D and E 
are equal, so the lemma follows trivially. 

CASE E contains some field declaration not in D : Since D and E differ only 
in their field and dependency declarations, the only uses in E of a field not in D 
are in dependency declarations (since D is a scope, which is closed). For any 
declaration 

depends a[t: T] on f[t] 

in E where a e E ^ D , TopDown(D, E) implies that / e E ^ D . So, fields 
in E ^ D can depend only on other fields in E n D . Since E is a scope, it is 
cycle-free, and thus there is some field among those in E \ D , call it e , such that 
there is no field / for which e on E f . 

Let H be the set E minus the declaration of e and minus any declaration of 
the form 

depends a[t: T] on s[t] 

for any a , t , and T . We have that H is a scope, that DC// and H c. E , and 
V/s(Z), //) , TopDown(D, H) , Vzs(//, £) , and TopDown(H, E) . We calculate, 

[VC D (m, C)] 

=>■ { induction hypothesis, with D, E := D, H } 

[VC H (m, Q] 

=>• { Soundness Lemma E, with D, E := H, E } 

[VC E (m, Q] 

Since under our premise D c. E , the two cases we have considered are ex- 
haustive, we have now proved the lemma. □ 
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A 18 Proving the Soundness Theorem 



In this section, we prove the Soundness Theorem from the Soundness Lemmas of 
the previous three sections. 

Proof of Soundness Theorem. Let D and E be scopes satisfying the antecedent 
of the theorem. We define sets of declarations G and H such that G is D union 
the type declarations of E and H is G union the field and dependency declara- 
tions of E . Sets H and E hence differ only in their rep, method specification, 
and method implementation declarations, and we have 

D c G c H c E 

Furthermore, G and H are scopes, and the following properties hold: Vis(D, G) , 
TopDown(D, G) , Vis(G, H) , TopDown{G, H) , Vis(H, E) , and TopDown{H, E) . 
We calculate, 

[VC D (m, Q] 

=>• { Soundness Lemma A with D, E := D, G } 

[VC G (m, Q] 

=>■ { Soundness Lemma F with D, E := G, H } 

[VC H (m, Q] 

=>■ { Soundness Lemma B with D, E := H, E } 

[VC E (m, Q] □ 

So, we have proved the Soundness Theorem from the Soundness Lemmas, but 
we're not done yet, because we have deferred the proof of Soundness Lemma C. In 
the remaining sections of Part III of this appendix, we prove Soundness Lemma C. 

A 19 Consequences of the modularity requirements 

In this section, we prove three lemmas that follow from the definitions of Vis and 
TopDown . 

Lemma. Let scopes D and E satisfy D c E, Vis(D, E) , and TopDown(D, E) . 
Then, 

(Vx, y :: x e D A y e D A xon* E y =>• xon* D y) (29) 
That is, the larger scope introduces no new dependencies of old variables. 
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Proof. To prove this lemma, we first formalize "reflexive, transitive closure of 
on D ": for any scope D , any x and y , and any natural number n , we define 

x on^ y = x £ D A x = y 

xon"^~ l y = {3 a :: x on n D a A aon D y) 

We thus have 

{VD,x,y :: xon*y = {3n :: xon^y)) (30) 

and 

{VD,x,a,y :: x on^ a A a on/) y =>• x on^ y ) (31) 

Using the new notation, we rewrite the lemma as follows: 

(Vxj :: x £ D A y £ D A xon* E y =>• x on* D y } 
{ (30) } 

(Vxj :: x £ D A y £ D A {3n :: xon^y) =>• x on^ y } 
= { predicate calculus } 

( Vx, y, n :: x £ D A y £ D A x on" E y =4> x on* D y } 

We prove this formula by induction on n . 
Case n = 0 : 

x£DAy£DAx on E y 

=► { 04 } 

x £ D A x = y 
=>• { on^ and on^ } 
x on^ y 

Case « = k + 1 : 

xeDAyeDAx on| +1 y 
{ o4 +1 } 

x£D A y£D A {3 a :: x on| a A a on £ y } 
=>• {by TopDown(D, E) , y £ D A a on E y =>• a e D } 

xeDAyeDA (3a::aeDAx on| a A a on £ y } 
=>• {by Vz'5(D, E) , a £ D A y £ D A a on E y =>• a on D y } 

xeDAyeDA (3a:: a £ D A x on| a A a on D y ) 
=>■ {by induction hypothesis, xeDAaeDAx on| a =>■ x on^ a } 
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xGDAyGDA {3 a :: a G D A x on* D a A a on D y } 
=>• { (31): xon* D a A aon D y =>• jc on^ y } 

jcgDajgDa (3a :: aefl m on* D y ) 
=>• { predicate calculus } 

on^ y 

That proves lemma (29). □ 



Lemma. Let scopes D and £ satisfy D c E, Vw(Z>, £) , and TopDown(D, E) . 
Then, for any modifies list w in D and any field or residue variable x in D , 

(Ve :: g c/ D (w) = G c/ £ (w) ) (32) 

Proof. The proof is by mutual implication. One direction is that cl D is mono- 
tonic with respect to D , which follows from that on D , and thus also on^ , is 
monotonic in D : 



x[e] G cl D (w) 
= { (20): definition of cl D } 

(3/ :: f[e] G w A /on* x) 
=> { D c £ a / on*, x f on* x } 

(3/ :: f[e] £w A / on* x) 
{ (20): definition of cl E } 

x[e] G cl E (w) 

For the other direction, 



x[e] G c/ £ (w) 
= { (20): definition of cl E } 

(3/ :: f[e] G w A / on* * } 
=>• { /[e] e w =>• f € D , and 

by lemma (29), / gDaxgDa / on* E x =>• / on^ jc } 

(3/ :: /[e] G w A /on^jc) 
= { (20): definition of c/ D } 

^[e] G cfoOv) 

That proves lemma (32). b 
The third lemma is a simple corollary of the second lemma: 
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Lemma. Let scopes D and E satisfy D c E , Vis(D, E) , and TopDown(D, E) . 
Then, for any modifies list w in D, any field or residue variable x in D , and any 
dummy s, 

modpointoix, w, s) = modpointE(x, w, s) (33) 
Proof. We calculate, 

modpointoix, w, s) 
= { (22): definition of modpointo } 

( V e I x[e] e cl D (w) :: s = e } 
= { lemma (32) } 

( V e I X W e cl E {w) :: s = e) 
= { (22): definition of modpoint E } 

modpointE(x, w, s) □ 

A20 A property about modification points 

In this section, we prove a lemma about modification points. 

Lemma. For any scope D and modifies list w in D , let / be a field not listed in 
w (that is, for all e , f[e] gw). Then, 

[modcon D (w,f,f) =>■ modcon D (w,f, sres)] (34) 

Proof. For any user expression e , we calculate, 

f[e] e c/ D (w) 
= { (20): definition of d D } 

(3g :: e w A gon^/} 
= { / is not listed in w , so /[e] ^ w } 

(3g :: e w A gon^/ a g^f) 
=>■ { definitions of on^ and on D } 

(3g :: g[e] e w A g is abstract } 
=>• { definitions of on D and on^ } 

(3g :: g[e] e w a gon* D sres } 
= { (20): definition of cl D } 

sres[e] e cfoOv) 
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Therefore, 



modpoint D (f, w, s) 
= { (22): definition of modpoint D } 

(V« I f[e] e c/ D (w) :: 5 = e) 
=>■ { calculation above } 

( V e | smsfe] e c//)(vv) :: s = e ) 
= { (22): definition of modpoint D } 

modpointoisres, w, s) 

Thus, we prove lemma (34) as follows: 

modcon D (w , f , /) 
= { (24): definition of modcon D } 

w:(V5 :: F D (f[s] =f[s] v modpointD(f,w, s)) ) 
= { calculation above, and (19): monotonicity of F D } 

w.{Vs :: F D (f[s]=f[s] v modpoint D (sres,w, s)) } 
= { (24): definition of modcon D } 

modcon D (w,f, sres) □ 



A21 Properties of liberal preconditions 

We now start a three-section journey that culminates in a lemma at the heart of 
our soundness proof, regarding liberal preconditions, individual residue variables, 
and variables not in scope. 

In this section, we define a variation of weakest liberal preconditions that ig- 
nores the possibility of commands going wrong, ultra-liberal preconditions, writ- 
ten ulp , and develop some properties of wlp and ulp . 

For any scope D , command C in D , and vanilla expression Q in D that 
contains no free occurrences of post-adorned fields or residue variables, the vanilla 
expression ulp D (C,Q) characterizes those pre-states ps of C such that 

• every terminating execution of C from ps ends in a post-state that satisfies 

Q. 

Note that unlike wlp D (C, Q) , ulp D {C, Q) does not guarantee that executions do 
not go wrong (cf. Section A8). The fact that this is the only difference between 
wlp D and ulp D is captured by the following relation: for any D, C,and Q, 

[wlp D (C, Q) = wlp D (C, true) A ulp D (C, Q)] (35) 
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This relation is in fact the same relation as between Dijkstra's weakest precon- 
ditions, which account for non-termination, and weakest liberal preconditions, 
which ignore non-termination [9]. 

We define ulp D (C, Q) inductively over the syntactic structure of C . Except 
for the assert command and the method call command, ulp D is defined like wlp D 
in Section A8, but with occurrences of wlp D replaced by ulp D . For the assert 
command, we define 

ulp D (assert e, Q) = true A Q 

And for any method m whose specification, after renaming its parameter to a 
fresh dummy t , is 

method m(t: T) requires p modifies w ensures q 



ulp o(cal\ m(e), Q) = 
(W :: t = F D (e) => 
true A 

(Viz :: zz = zz =>■ (Viz :: zz = zz =>■ 
(Viz :: F D (q) A mc D (w) =>• 

(Viz :: zz = zz =>■ (Vzz :: zz = zz =>■ 2 }}}}}} 

where zz is the list of concrete fields and residue variables in D , and ii denotes 
fresh adornments of zz . 

From the definitions of w//?/) and wlpo , one can easily prove property (35). A 
simple consequence of (35) is: for any D , C , and Q , 



An important property of ulp D is that it is conjunctive in its second argument: 
for any scope D , command C in D , and predicates QO and <21 , 



This property can easily be proved from the definition of ulp D . 

Similarly, one can prove from the definition of wlp D that wlp D also is con- 
junctive. Furthermore, conjunctivity implies monotonicity [10], so we have that 
wlpo is monotonic in its second argument. That is, for any scope D , command 
C in D , and predicates QO and Q\ , 



we define 



[wlp D (C,Q) => «/p D (C,0] 



(36) 



[ulp D (C, QO A Q\) = ulp D (C, QO) A ulp D (C, Ql)] 



(37) 



[20 => Ql] => Mp D (C, 20) => w/po(C, 21)] 



(38) 
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Another property that follows from (35) and (37) is: for any scope D , com- 
mand C, and predicates QO and Q\ , 

[wlp D (C, QO A Q\) = wlp D (C, QO) A ulp D (C, Ql)] (39) 

We end this section by proving one more lemma about ulp . This lemma, 
which we will use a couple of sections from now, lets us restrict our attention to 
D -free commands in certain cases. 

Lemma. For any scope D , command C in D, and sufficiently large set of fresh 
variables ss , there exists a non-negative integer n and a set of D -free commands 
U I 0 < j < n :: Q } such that for any predicate Q that has no free occurrences 
of any variable in ss , 

[ulp D (C, Q) = < /\j I 0 <j < n :: ( V ss :: ulp D (Cj, Q) }}] (40) 

Remark: more precisely, the set ss is "sufficiently large" when it contains at least 
one fresh variable for every var . . . end command in C . 

Proof. We prove the lemma by induction over the structure of commands. We 
consider four cases. 

CASE D -free commands: For commands that are already D -free (including the 
inherently D -free commands simple assignment, field update, assert, assume, and 
method call), the lemma follows trivially (with n, Cq := 1, C). 

Case var s in C end : Let t be one of the fresh variables in ss , and let tt denote 
the rest of the variables. We calculate, 

ulp D (\ar s in C end, Q) 
= { rename s to t in C and call the result C } 

ulp o(var t in C end, Q) 

= { ulp D } 

<W :: ulp D (C',Q)) 
= { induction hypothesis, with C, ss := C, tt } 

<W :: (Ai I 0<j<n :: (Vtt :: ulp D (Cj, Q) ))) 
= { predicate calculus } 

( A7 I 0 <j < n :: (Vt,tt ulp D (Cj, Q) )) 

Case CO D CI : Divide ss into two sufficiently large parts, tt and uu . Then, 

ulp D {C0 D CI, 0 
= { ulp D } 
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ulp D (CO,Q) A ulp D (C\,Q) 

{ induction hypothesis, with C, ss := CO, tt and with 
C, ss := CI, mm } 
( Ay I 0 <j < m :: (Vtt :: # D (q, 0 )} A 
(Ay I 0<j<n :: ( V mm :: ulp D {C p Q))) 

{ for 7 :0<7<n,let C m+7 - := Cj } 
( Ay I 0 <j < m :: (Vtt :: ulp D (Cj, Q) )) A 
( Ay I 0 <y < " " (Vkm :: ulp D (C m+j , Q) )) 

{ predicate calculus } 
( Ay I 0 < i < m + n ■■ {Vtt,uu :: ulp D (Q, Q) }) 



Case B ; C : Divide ss into two sufficiently large parts, tt and mm . Then, 
ulp D (B ; C, Q) 

= { ulp D } 

ulp D (B, ulp D (C, 0) 
= { induction hypothesis, with C, 55, Q := 5, M, ulp D (C, Q) } 

( AM 0 < i < m :: ( Vtt :: ^(5,-, m//> d (C, 0) )) 
= { induction hypothesis, with 55 := mm } 

( AM 0 < / < m :: (Vtt :: ulp D (Bi, 

( AM 0 <j < n :: (Vmm :: M/ Pz) (C y , 0 }}) }} 
= { (37): ulp D is conjunctive } 

( AM 0 < i < m :: (Vff :: ( /\j \ 0 <j < n :: (Vmm :: 
ulp D (B h ulp D (Cj, 0) }}}} 
= { predicate calculus } 

( A U I 0 < i < m A 0 <j < n :: {V tt,uu :: ulp D {Bi, ulp D (Q, 0) }} 
= { w/pz) } 

( A U I 0 <i < m A 0 <j < n :: {Vtt,uu :: ulp D (Bi ; Cy, 0 )) 

Since we have now considered an exhaustive set of cases, we have proved the 
lemma. b 



A22 Chain of Equalities Lemma 

In the informal proof sketch for Soundness Lemma C (page 93), we argued that in 
the large scope, m 's body C establishes modcon E (w, s, s) , where w is the modi- 
fies list of m , because in the small scope, C establishes modcon D (w, res.a, res.a) 
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for each abstract variable a that depends on e . In the next three lemmas, we make 
this argument formal. 

Each occurrence in C of a method call leads to a modification constraint in 
the VC of the form 

{"is:: res.dj[s\ = res.dj + \[s\ v modpointo(res.a,v, s) ) (41) 

which is assumed about the call (where v is the modifies list of the called method, 
and the subscripts j and j + 1 indicate whatever adornments the VC generator 
used when it processed that method call). The VC also contains the modification 
constraint 

{"is :: res.ao[s] = res.a n [s] v modpointD(res.a,w,s)) (42) 

as a proof obligation (where res.a 0 and res.a n are the initial and final values of 
res.a ). The validity of the VC implies that (42) follows from the various instances 
of (41). An obvious way in which (42) can be proved to follow from the various 
instances of (41) is to show, for each instance, that -<modpoint D (res.a, v, t) holds 
(in the context of the VC) for each t such that ->modpoint D {res .a, w, t) . In fact, 
we claim that this is the only circumstance in which (42) follows from the various 
instances of (41). This claim is the formal version of the fact that there is no way 
to undo a side effect to a residue variable. The claim is useful because, when 
combined with the connection between the modification points of s and those 
of the abstract variables that depend on e , it proves that modcon E (w, s, s) also 
follows from the same instances of (41). The essence of the proof of this claim is 
the Chain of Equalities Lemma, which follows next. 

To understand this lemma, it may help to first state a simpler property and then 
explain in which ways the Chain of Equalities Lemma is more complicated. The 
simpler property is: 

Let a , b , and c be variables, and let P , K , and L be predicates 
independent of a , b , and c (that is, the predicates contain no free 
occurrences of these variables). Then, 

[Pa (a = b v K) A (b = c v L) =>• a = c] 
[Pa (a = b v K) A (b = c v L) =^ —<K A -<L ] 

This simpler property says that if the equality a = c follows from the antecedent 
"Pa . . . ", then so does -<K A -<L . Informally (and somewhat imprecisely), the 
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reason the simpler property is true is that the antecedent contains no information 
about the variables a , b , and c , and thus the only way to conclude a = c is to 
first conclude the chain of equalities a = b and b = c , which can be achieved 
only by establishing —>K A —>L . 

The simpler property is true, and it resembles the Chain of Equalities Lemma. 
But the latter lemma is more complicated in four ways. 

First, instead of three variables a , b , and c and two predicates K and L , we 
have a sequence of n + 1 variables a Q , . . . , a n and n predicates K 0 , . . . , K n _\ . 

Second, P and the Kj 's are not entirely independent of the variables, but 
only "almost independent", a notion that involves a given uninterpreted function 
/ (corresponding to an abstraction function). 

Third, instead of equalities between entire variables, the Chain of Equalities 
Lemma concerns equalities between indexed map variables. 

Fourth, the predicate P is replaced by Q A P , where Q provides properties 
of / (corresponding to rep axioms and pointwise axioms). 

Here's the definition of almost-independence: for any uninterpreted function 
symbol / and set of variables aa , we say an expression P is almost independent 
of aa with respect to / when 

• the only free occurrences of the aa variables in P appear as the first argu- 
ment to / , and 

• every application of / has a free occurrence of one of the aa variables as 
its first argument. 

We use the following properties of the select and store functions: 

( Vm, ij, v :: i=j store(m, i, v)\j] = v ) A 
( Vm, ij, v :: i #j =>■ store(m, i, v)\j] = m{j] ) 

( Vm, n :: m = n = (V s :: m[s] = n[s] }} (44) 
(Advanced remark: Part IV of this appendix has more to say about property (44).) 

Chain of Equalities Lemma. Let / be a 2-argument uninterpreted function sym- 
bol, let n be a non-negative integer, and let aa denote a set of n + l variables 
{j I 0 <j < n :: a } } . Define Q as: 

( Vx, y, z, s :: M(y, z, s) => f(x, y)[s] = z ) A 

(Vw,x,y,z,s :: w[s] = x[s] A N(y,z,s) =>• f(w,y)[s] =f(x,z)[s] ) 
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where M(y, z, s) and N(y, z, s) are predicates independent of / and of the vari- 
ables in aa . Let P be a predicate almost independent of aa with respect to / . 
For any j: 0 < j < n and any dummy variable s , let Kj(s) be a predicate almost 
independent of aa (with respect to /). Let S denote 

Q A P A ( /\j I 0 <j < n :: (Vj :: a,[s] = a j+l [s] v ^(5) )) 

Then, for any h:0 < h < n and any ? not in , 

[5 => floW=fl«W] => [5 => (45) 
(End of Lemma.) 

The everywhere brackets say a given formula is valid. Elsewhere in this 
appendix, we take this to mean that the everywhere brackets implicitly quantify 
over all variables and uninterpreted function symbols. Equivalently, it means that 
the formula holds in all models. 

We prove the lemma by proving its contrapositive: from a model 4> that is a 
counterexample to "5 =>• ->K h {ty , we show a model \jf that is a counterexample 

to "5 => floW = a«W" • 

Let 0 be a counterexample to "5 =>• ->K h (ty' . That is, we have the following 
properties of 0 : 

0(0 A 0OP) A 

( Ai I 0 <j < n :: 0«Vs :: aj[s] = a j+l [s] V ^(5) }) } A (46) 
<KKh(t)) 

Let F = 0(f) , A, = 0(o,) for ;': 0 < 7 < n, and T = 0(0 . 

We will now construct a model \j/ that falsifies the antecedent of (45). The 
model ij/ will interpret the first h + 1 variables in aa as the /z + 1 maps Bj , 
j'-O <j < h . The most important part of each Bj is its value Bj[T\ . These values 
are defined to be any Vj ■, j: 0 < j < h , satisfying 

[j I 0 <j < h :: V/ } n {7 I h <j <n :: A 7 [rj } = 0 (47) 
(V/,7 I 0 < i <j < h :: V { = Vj = A i [T]=A j [T] ) (48) 

Condition (47) requires that the V 's be disjoint from the A ; [T] 's, and condition 
(48) requires that the V 's be partitioned by equality in the same way as the cor- 
responding Aj[T] 's. (Part IV of this appendix argues that V 's satisfying (47) and 
(48) exist in all of the models that matter.) 
Having chosen the V 's, we can now define 

Bj = store(Aj, T, Vj) 
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for ;': 0 < j < h . 

Model i/r will interpret / as a function G , defined by 

G = (kx, y :: if x[T] = Vj for some ;': 0 <j < h then 
F(store(x, T,Aj[T]),y) 

else 

F(x,y) 
end } 

Note that (48) implies that G is well-defined. 
For any j: 0 < j < h and any s , 

store(Bj, T,Aj[T])[s] 
= { (43): select and store } 

if s = T then Aj[T] else Bj[s] end 
= { Bj = store(Aj, T, Vj) , and (43): select and store with s ^ T } 

if s = T then Aj[T] else Aj[s] end 
= { cases of if . . . end are the same } 

Aj[s] 

and thus by select property (44), 

store(Bj,T,Aj[T]) =Aj (49) 
Consequently, for any j: 0 < j < h and any Y , 

G(Bj, Y) 

{ G since Bj[T] = Vj } 
F(store(Bj,T,Aj[T]),Y) 

{ (49) } 
F(Aj, Y) 

which shows 

G(Bj, Y) = F(Aj, Y) (50) 

Finally, we define \jf to be the following model: 

i/f = ( A v :: if v = "a/' for some j: 0 < j < h then Bj 
elsifv = T'thenG 
else 4> (v) 
end } 
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To prove the theorem, we need to prove that x/r is a counterexample to "5 =>• 
«oW = fl«W" • 

We continue by proving the following lemmita: for any expression e almost 
independent of aa, 

f(e) = He) (51) 

We prove this lemmita by induction on the structure of e . The only difference 
between <p an d if is how they interpret the function / and the variables aa . 
Almost-independence tells us that every occurrence of an aa variable appears 
as the first argument to some application of / . Hence, to prove the lemmita, it 
suffices to consider applications of / ; all other cases are trivial. Furthermore, 
almost-independence tells us that each application of / has one of the aa vari- 
ables as its first argument, so we only need to consider expressions of the form 
f(cij, e) for every j: 0 <j < n . We consider two cases. First, for j: 0 < j < h and 
any e almost independent of aa, 

f(f(oj, e)) 

{ t } 
G(Bj, f{e)) 

{ (50) with Y := f(e) } 
F(Aj, f{e)) 
= { induction hypothesis } 

F(Aj,<P(e)) 

{ 0 } 
4>(f(aj, e)) 

Second, for j:h <j < n and any e almost independent of aa , 

f(f{aj, e)) 
= { \\r and Aj = 0 (aj) } 

G(Aj, f{e)) 

{ (47) and G } 

F(Aj, f{e)) 
= { induction hypothesis } 

F(Aj,<f>(e)) 

{ <P } 
<p(f(aj, e)) 
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This proves lemmita (51). 

From this lemmita, we have 

f(P)=<f>(P) A 

( Ai I 0 <j < n :: (Vs :: f(Kj(s)) = <t>{Kj{s)) }> pz; 

From (46), we then also have 

f(P) (53) 

We continue by proving another lemmita: for any j: 0 < j < n and any 
dummy variable s , 

j^h v s^T => f(oj[s] = a j+1 [s]) = 4>(aj[s] = a j+1 [s]) (54) 

Technically, 0 and iff do not have any dummy variables in their domains. Thus, 
the proper way to write the consequence of this lemmita would be 

(VY :: iM'V » Y)(oj[s] = a j+l [s]) = 0('V ^ Y)(a,[s] = a, +1 M) ) 

where ^('V i-> Y) denotes function i/r extended to map "5" to Y. However, 
for brevity, and we claim without actual precision, we take 0 and \fr to map 
dummy variables to themselves, implicitly denoting any value. This allows us 
to state the lemmita the way we did and lets us avoid unnecessary clutter in our 
proof. Actually, this comment also applies to lemmita (51), where we shamelessly 
swept this issue under the rug. 

We prove lemmita (54) by considering four cases: 

h <j 

j < h A s T 

j < h A s = T 
j=h A s^T 

First, if h < j , then 

{ f } 
<f>(aj)[s] = 0(a,+i)M 

{ 0 } 
4>(aj[s\ = a j+ i[s]) 

Second, if j < h A s ^ T , then 
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f(aj\s\ = a j+ i[s]) 

{ f } 
Bj[s] = B j+1 [s] 

= { Bj ■, B j+ i , and (43): select and store, since s ^ T } 

Aj[s] = A j+l [s] 

{ <t> } 
<j>(aj[s] = a j+l [s]) 

Third, if j < h A s = T , then 

f(cij[s\ = a j+ i[s]) 

{ * } 
Bj[s] =Bj+i[s] 

= { Bj , Bj+i , and (43): select and store, since s = T } 

{ (48) } 
Aj[T] =A j+l [T] 
= { s = T and <p } 

(j)(aj[s] = a j+l [s]) 

Fourth, if j = h A s ^ T , then 

i/(a h [s] = a h+ i[s]) 

{ * } 
B h [s] = 4>(a h+ i)[s] 
= { B h and (43): select and store, since s ^ T } 

A h [s] = (p(a h+1 )[s] 

{ <t> } 
4>(Ah[s] = a h+ i[s]) 

This proves lemmita (54). 

We can now prove that ^ satisfies 

(Ai I 0<j<n :: V«Vs :: aj[ S ] = a j+l [s] V Kj(s) » > 
We consider two cases. First, if j ^ h, then 

f((Ws :: Oj{s\ = a j+l [s] V Kj(s) }) 
{ * } 

(V S :: ^W=«,+iM) v f{Kj{s))) 
= { (52), and lemmita (54) since j ^ h } 
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(Vs :: <Koj[s] = a j+1 [s]) v 0(i^(s)) } 
{ 0 } 

0((Vs :: Oj[s] =o,+iM v ^(s) }) 

Second, if j = h, then 

f((Vs :: = a h+1 [s] v i^(s) }) 
{ V' } 

(Vs :: ^r(fl*[j] = a h+l [s]) V f(K h (s))) 
= { split range } 

(Vj :: 5 # T f{a h [s] = a h+l [s\) V ^(j)) > A 

(Vs :: S = T => ^r(a A [j] = ^M) v f(K h (s))) 
= { (52), and lemmita (54) since s # T } 

(Vs :: 5 # r => 0(a*[,s] = a h+l [s]) V 0 } A 

(Vs :: 5 = r f(a h [s] = a h+l [s]) V 0 } 

{ r = 0(0 , and (46): <f>(K h (t)) , hence s = T => <p(K h (s)) } 

(Ws :: 5 # r => 0(a*[j] = V (p(K h (s)) } A 

(Vs :: 5 = T => 0(^(5)) } 

{ T = 0(0 , and (46): 0(^(0) , hence 5 = T => 0 } 

(Vs :: 5 ^ r => 0(a*[j] = fl A+ iM) v (p(K h (s)) ) A 

(Vj :: 5 = r => 0(a*[j] = a h+l [s]) v 0(^0)) ) 
= { combine range } 

(Vj :: 0(a*[j] =%iM) v 4>(K h {s)) ) 
{ 0 } 

0((Vs :: a h [s] = a h+l [s] V ^(j) }) 
That proves (55). 

We have two things left to prove before we can conclude that \fr is a coun- 
terexample to "5 =>• cio[t] = a n [tY' : checking that Q holds under ^ and 
checking that the consequent does not hold under \js . We continue by working on 
the latter, and thus prove: 

f(a 0 [t]^a n [t]) (56) 
= { x/r > since 0 < h < n } 

B 0 [T]^A n [T] 

= { Bq = store(A 0 , T, V 0 ) » and (43): select and store } 

= { (47), since 0 <h < n } 
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Finally, using the fact that applying 0 in the conjunct <p(Q) of (46) yields 

(Vx,y,z,s :: <t>(M(y,z,s)) => F(x, y)[s] = z } A (57) 
(Vw,x,y,z,s :: w[s]=x[,s] A <p(N(y,z,s)) =>• 

F(w,y)M=F(*,z)M) PS; 

we show: 

iA(0 (59) 
For the first conjunct of Q , we calculate, 

VK(Vx,y,z,5 :: M(y,z,s) => f(x,y)[s] = z » 
{ * } 

(Vjcj,z,j:: ^<My,z,s)) => G(x,y)[s]=z) 
= { M(y, z, s) is independent of / and aa } 

(Vx,y,z,s:: 0(M(y,z,s)) => G(x, y)[s] = z ) 

We consider two cases. First, if is not among the V 's (that is, if there is no 
<j < h such that x[T] = Vj ), we have 

G(x,y)[s] = z 
= { G, since x[T] is not among the Vs } 

F(x,y)[s] = z 
<= { (57) } 

4>(M(y,z, s)) 

Second, for any j: 0 < j < h such that x[T] = Vj , we have 

G(x,y)[s] = z 
= { G , since x|T] = VJ- } 

F(store(x, T,Aj[T]), y)[s] = z 
<^= { (57) with x := store(x, T,Aj[T]) } 

4>(M(y,z, s)) 

Now for the second conjunct of Q , we calculate, 

f((Vw,x,y,z,s :: w[5]=x[5] A N(y,z, s) => f(w,y)[s]=f(x,z)[s])) 
{ + } 

(Vw,x,y,z, s :: w[s] = x[s] A f(N(y,z,s)) =>• G(w,y)[s] = G(x, z)[s] ) 
= { 7Y(y, z, 5) is independent of / and aa } 

(Vw,x,y,z,s :: w[s] = x[s] A <p(N(y,z,s)) =>■ G(w,y)[s] = G(x, z)[s] ) 



120 



We consider three cases. First, if neither w[T] nor x[T] is among the V 's, then 

G(w,y)[s] = G(x, z)[s] 
= { G , since neither w[T] nor x[T] is among the V's } 

F(w,y)[s]=F(x,z)[s] 
<= { (58) } 

w[s] =x[s] A (f)(N(y, z, s)) 

Second, if exactly one of w[T] and x[T] is among the V 's, say w[T] = Vj , then 
we note that w[T] ^ x[T] and calculate, 

G(w,y)[s] = G(x,z)[s] 
= { G, given assumptions about w[T] and x[T] } 

F(store(w, T,Aj[T]), y)[s] = F(x, z)[s] 
<^= { (58) with w :=store(w, T,Aj[T]) } 

store(w,T,Aj[T])[s]=x[s] A (f>(N(y, z, s)) 
= { (43): select and store } 

(s = T => Aj[T] = x[T]) A (s # T => w[ S ] = A 0(JV(y, z, 5)) 
<^= { w[7] # x[7] , and thus vacuously w[T] = x[T] => A y |T] = x|T] } 

(5 = T => w[7] = A (s # T => w[s] = x[s]) A 0(JV(y, z, s)) 

= { combine cases } 

w[s] =x[s] A (f)(N(y, z, s)) 

Third, if both w[T] and x[T] are among the V 's, say w|T] = V, and jc[T] = V/ , 
then 

G(w,y)[s] = G(x,z)[s] 
= { G, since w[T] = V t and x[T] = Vj } 

F(store(w, T, A t [T]), y)[s] = F{store(x, T,Aj[T]), z)[s] 
<^= { (58) with w, x := store(w, T,Ai[T]), store(x, T,Aj[T]) } 

store(w, T,Ai[T])[s] = store(x, T,Aj[T])[s] A <p(N(y, z, s)) 
= { (43): select and store } 

( S = T => A i [T]=A j [T]) A (s^T => w[s] = x[*]) A 0(tf(y,z,,s)) 
{ (48), and w[r] = V,- and x|T] = Vj } 

( s = t => w[r] = x[r]) a (5 # r => = x[s]) a 0(W(y, z, 5)) 

= { combine cases } 

w[s] =x[s] A (/)(N(y, z, s)) 

With that, we have proved (59). 

Formulas (59), (53), (55), and (56) show that ^ is a counterexample to "5 =>• 
a 0 [t] = a n [t]" , which completes the proof of the Chain of Equalities Lemma. □ 
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A23 Chain Rewriting Lemma 



Recall the simple argument that we are formalizing: VC D (m, C) is valid, hence 
C respects the modification constraint for res. a , for each a that depends on s . 
Hence each procedure call in C respects these constraints, from which it can be 
concluded that C itself respects the modification constraint for e . The Chain of 
Equalities Lemma is our essential tool for formalizing this argument, but there is 
still an argument required to show that VC D (m, C) can be written in a form to 
which the Chain of Equalities Lemma applies. This argument is a structural in- 
duction on the command C . We show by induction that the verification condition 
is equivalent to an implication in which the antecedent is a conjunction to which 
the Chain of Equalities Lemma applies. The exact inductive assertion is a lemma 
that we call the Chain Rewriting Lemma. 

The setting of this lemma is as follows. Let E be any scope, s a concrete 
field in E , and zz the list of concrete fields and residue variables in E . Let xx 
denote the list consisting of e and the residue variable res.a for each a such that 
a on £ e . 

The verification conditions that are the subject of our inductive proof can con- 
tain many adorned variables, so in this lemma, we will adorn variables with nu- 
merical subscripts instead of with accents. We will even use negative subscripts, 
so that, for example, x 0 , X- 3 , and xn are three adornments of x . The relevant 
adornments of each variable are always a linear sequence, whose subscripts range 
from —2k to 3k + 1 for some natural number k . The first adornment, x_ 2 k , 
represents the input value x and the last adornment, x 3k+i , represents the current 
value (default adornment) x . Therefore, for any k , we define a k -replacement to 
be a substitution 9 such that for any x in xx , 

xQ = X-2k and x9 = x^k+i 

A A: -replacement may also arbitrarily rename local- variable scalars. 

We next define a predicate chain . For any sequence a of modifies lists in 
E , any x in xx, and any integer k, chain x (a, k) asserts a relation between the 
adornments of x from X-2k to x^+i : pairs of adjacent x 's are either equal or are 
related as allowed by one of the modifies lists in a . In particular, one fifth of the 
pairs are constrained by a modifies list in a , and the other pairs are constrained 
to be equal. (The reason for this strange definition is that the wlp equation for 
method call avoids variable capture by introducing five dummies, one of which is 
constrained by a modifies list.) Formally, we define chain x (a, k) as: 

( Ai I — 2k < j < 3k + \ :: ( V s :: Xj [s] = Xj +1 [s] V Kj(x, a,s))) 
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where 



Kj(x, a, s) = if 0 < 7 A i = (j — 2)/3 for some integer i then 

F E (modpoint E (x, a u s))(zz := zzj) 

else 

false 

end 

The definition implies equality between four out of five adjacent adornments, be- 
cause due to select property (44), 

Xj = Xj + i = ( V s :: Xj[s] = Xj + \[s] v false ) 
Note that 

chain x (a, 0) = Xo = X\ 
and that 

chain x (a, k + 1) = (60) 
chain x (a, k) A 

X-2k-2 = X-2k-l A X-2k-\ = X-2k A -^/t+l = %Zk+2 A 

(Vs :: i 3 { +2 M =^3/t+3M v F E {modpoint E {x,a k ,s))(zz:= zzz k +i) > A 

From the definitions of modpoint E and F £ , we observe, for any x , w , and s , 
F E (modpoint E (x, w, s)) is independent of zz (61) 

Finally, we define 

chainia, k) = ( f\x \ x e xx :: chain x (a, k) ) 

In this setting, we now state the lemma: 
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Chain Rewriting Lemma. For any D -free command C in E that does not assign 
directly to s , any sequence a of modifies lists in E , and any k -replacement 0 , 
there exist 

• a predicate P such that, for every individual residue variable res.a in xx 
for an abstract field a, P is almost independent (page 113) of res.a with 
respect to function T.a , 

• a sequence ft of modifies lists in E , 

• an integer I , and 

• an I -replacement o , 

such that for any predicate Q and for any predicate R whose free variables are 
not post-adorned, 

[Q A chain(a,k) =>• ulp E (C,R)0] = 

[Q A P A chainifi, i) => Ra] { } 

(End of Lemma.) 

Proof. We prove the lemma by induction over the structure of C . We consider a 
number of cases, each of which is proved by a calculation that ends with suitable 
£ , I , o , and P . 

Case s := e : 

[Q A chain(a, k) =>• uIpe(s := e, R) 9] 

= { ulp E } 

[Q A chain(a,k) => (Vs' :: s' = F E (e) ^ (V s :: s = s' ^ R )) 9] 
= { distribute quantification over s' out (since s' is fresh), then absorb 

it into the everywhere brackets; predicate calculus } 

[Q A chain(a,k) A s'=F E (e)9 => (V s :: s = s' => 7? ) 0] 
= { rewrite quantification as a substitution } 

[2 A chain(a, k) A s' = F E (e) 9 => := *') 0] 

which is the right side of (62) with ft := a , £ := fc, er := (5 := s')0, and 
P :=s' = F E (e) 9 . 

Case c[<?0] := el : 



124 



[Q A chain(a,k) =>• ulp E (c[eO] :=e\,R)0] 

= { ulp E } 

[Q A chain(a, k) =>■ 

(Vc' :: d = store (c, F E {eO), F E (e\)) => (V c :: c = d => J? » 0] 
= { predicate calculus, since c' is fresh } 

[2 A chain(a,k) A d = store(c, F E (eO), F E (el)) 6 =>• 

(Vc :: c = c' => 7? ) 0] 
= { rewrite quantification as a substitution } 

[Q A chain(a,k) A d = store(c, F E (eO), F E (el)) 0 R(c:=d)6] 

Case assert e : 

[Q A chain(a,k) =>• ulp E (assert e, R) 0] 
= { ulp E } 

[Q A chain{a,k) ^ R0] 

Case assume e : 

[Q A chain(a, k) =>• M/p £ (assume <?, 7?) 0] 

= { m/P£ } 

[2 A chain{a,k) => (F £ (e) => 7?) 0] 
= { predicate calculus } 

A chain(a,k) A F E (e)6 =^ R9] 

Case CO ; CI : 

[Q A chain(a,k) => ulp E (C0 ; Cl,/?)0] 

= { ulp E } 

[Q A chain(a,k) =>• ulp E (C0, ulp E (Cl, R)) 9] 

= { induction hypothesis, with C, 7? := CO, ulp E {C\,R) } 

[2 A P A chain(fi,l) => ulp E (Cl, R) a] 

= { induction hypothesis, with 2, k, C, 0 := Q A P, i, CI, a } 

[Q A P A P' A chain(y,m) =>• 7?t] 

Case var 5 in C end : We assume 5 is a fresh name. 
[Q A chain(a, k) =>• ulp E (\ar s in C end, 7?) 0] 

= { W^Pe } 

[2 A chain{a,k) =>• (Vs :: ulp E (C,R) } 6] 
= { predicate calculus, since 5 is fresh } 
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[Q A chain(a,k) =>• ulp E (C, R) 0] 
= { induction hypothesis } 

[Q A P A chain(P,£) => Rcr] 

CASE call m(V) : Assume the specification of m , after renaming its parameter to 
a fresh dummy t,is 

method m(t: T) requires p modifies w ensures q 

We calculate, 

[Q A chain(a,k) =>• ulp E (call m(e), R) 9] 

= { ulp E } 

[Q A chain{a,k) =>• (W :: t = F E (e) =>• 
(Viz :: iz = zz =>■ (Vzz :: zz = zz =>■ 
(Vzz :: F £ (^r) A mc £ (w) => 

(Vzz :: zz = zz => (Vzz :: zz = zz => /? }}}}}} 0] 
= { predicate calculus, and rename zz, zz, zz, zz, zz to 

ZZ-2*-l, ZZ3/t+2, ZZ3k+3, ZZ-2k-2, ZZ3k+4 } 

[Q A chain(a, k) A t = F E (e) 9 =>• 

(Vzz_ 2y t-i :: zz- 2 ^-i=iz =>• (Vzz 3(t+2 :: zz 3 i+2 = zz =>• 
(Vzz 3yt+3 :: (F E (q) A mc E (w))(zz, zz := zzu+2, zzu+3) =^ 

(VzZ_2i-2 " ZZ-lk-l = ZZ-U-1 =>■ (VzZ3/t+4 " ZZ3/t+4 = ZZ3/t+3 =>" 
i?(ZZ, ZZ := ZZ-2*-2, ZZ3/t+4) }}}}} 6>] 

= { predicate calculus } 

[2 A chain(a,k) A t = F E (e)0 A zz-u-i = zzO A zz3k+2 = zz9 A 

(F E (q) A mc E (w))(zZ,ZZ:= ZZ3k+2,ZZ3k+3) A ZZ-2&-2 = ZZ-U-l A 
ZZ3/1+4 = ZZ3i+3 

# (ZZ, ZZ := ZZ-2/t-2, ZZ3k+4) 9] 

= { let yy denote the list of variables in zz but not in xx , 

let mc x ^(w) = ( /\x | ie« :: modcon E (w, x, x) ) , and 
let mcf (w) = ( /\y | y e yy :: modcon E (w,y,y) ) } 
[Q A chain(a, k) A t = F E (e) 9 A 

xx-2k-i =xx9 A yy-2k-\ =yy9 A xx 3 k+2 =xx9 A yy 3 k+2 = yy 9 A 
(F E (q) A mc%(w))(zz, zz := zz 3 /t+2, zz 3 /t+3) a 
mc x E x (w)(zz, zz := zz 3 k+2, zzs^+s) a 

XX_2*-2 = XX_2k-l A yy_ 2 yt-2 = JJ-2/t-l A 

^3it+4 = **3fc+3 A yy-ik+4 = yy3k+3 
=>• #(ZZ, ZZ := ZZ-2/t-2, ZZ3/t+4) #] 

= { 9 is a -replacement, hence ix# = xx- 2 k and xe(9 = xx^+i } 
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[Q A chain(a, k) A t = F E (e) 0 A 

xx-2k-i =xx-2k A yy-u-i = yyO a xx 3k +2 = xx 3 k+i a yy 3k+2 =yyO A 

(F E (q) A mc y l (W))(ZZ, ZZ := ZZ 3 k+2, ZZ3k+3) A 

mc^(w)(zz, zz := zz 3k +2, zz 3/ t+3) a 
xx_2k-i =xx_2k-\ a yy-2k-i =yy-2k-\ a 

XX 3k +A = XX3k+3 A yy3k+4 = yy3k+3 
=>• # (iz, ZZ := ZZ-2/t-2, ZZ3/1+4) 0] 

= { let yS be the sequence a but with f} k = w , and apply (60) and 

(61) } 

[Q A chain(P, k + 1) A t = F E (e) 9 A 

yy-2k-\ =yy0 a yy 3 k+2 =yy0 a 

(F E (q) A mc E (w))(zz, zz := zz 3 ,t+2, zz3k+3) A 

yy-2k-2=yy~2k-\ a yy3k+A = yy3k+3 

R(ZZ, ZZ := ZZ-2k-2, ZZ3k+4) 0] 

Note that (zz, zz := zz-ik-i, zz3k+4) 0 is a (k + 1) -replacement, which completes 
the case for method calls. 

We have now exhausted all cases (since C is D -free), and thus we have 
proved the Chain Rewriting Lemma. □ 

We define a meta function mcr representing modification constraints for rel- 
evant residue variables. For any scopes D and E such that D c E , any modifies 
list w in D, and any concrete field s in E but not in D , we define mcr E {w) to 
be the following predicate: 

( f\ a | a is an abstract field in E A a on £ e :: 

modcon E (w, res.a, res.a) ) 

We now wrap up the Chain of Equalities Lemma and the Chain Rewriting 
Lemma into a lemma at the heart of the proof of Soundness Lemma C. The lemma 
says that if C respects the modification constraints for the relevant residue vari- 
ables, then C respects the modification constraint for e . 

Chain of Equalities Corollary. For any scopes D and E such that D c E , any 
user expression p , modifies list w , and command C in D , and any concrete field 
s in E but not in D , 

[BP E A Rep E A PW E a F E (p) => (Viz :: zz = zz => 

ulp E (C, ( Vzz :: zz = zz =>■ mcr £ (w) )) }] 

=> 

A 7?ep £ A PW E A F E (p) => (Viz :: iz = zz => 

ulp E (C, (Vzz :: zz = zz =>■ modcon E (w, e, e) }) }] 
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where zz denotes all concrete fields and residue variables in E . 

Proof. We begin by showing that it suffices to consider D -free commands. Let S 
abbreviate the antecedent BP E A RepE A PWe a F E (p) , let ss be a sufficiently 
large set of fresh variables, and let n and {j | 0 < j < n :: Cj • } be like in lemma 
(40). Then, 

[S =>• (Vzz :: zz = zz =>■ ulp E (C, (V zz :: zz = zz =>• mcr £ (w) }) }] 
= { lemma (40) } 

[5 => {V zz :: zz = zz ^ ( Ai I 0<j <n :: (Vss :: 

ulp E (Cj, (Vzz :: zz = zz =>• mcr E (w) }) }))] 
= { predicate calculus } 

( Ai I 0 <7<n :: (Vss :: [S => (Vzz :: zz = zz => 

ulp E (Cj, (Vzz :: zz = zz =>• mcr £ (w) )) }] )) 
=^ {a version of the Chain of Equalities Corollary for D -free 

commands, to be proved } 

( Ai I 0 <j < n ( yss \- s =>■ :: zz = zz =^ 

ulp E (Cj, (Vzz :: zz = zz =>■ modcon E (w, s, s) }) )] )) 
= { predicate calculus } 

[5 =^ {V zz :: zz = zz ^ ( Ai I 0 <i < " :: " 

ulp E (Cj, (Vzz :: zz = zz =>■ modcon E (w, s, s) )) ))}] 
{ lemma (40) } 
[S =>• (Vzz :: zz = zz =>■ 

ulp E (C, (Vzz :: zz = zz =>■ modcon E (w, s, e) )) )] 

Thus, from now on, we assume C to be D -free. 

Since w is in D but e is not, e is not mentioned in w , and so with a ranging 
over the abstract variables in E , 

[modpoint E (s,w, t) = ( \J a \ aon E e :: modpoint E (a,w, t) )] 

From (23), we then have, with res.a denoting the residue variable of a , 

[modpoint E (s,w, t) = ( \J a \ aon E e :: modpoint E (res.a,w,t))] (64) 

For any abstract variable a , let QR a be the conjunction of all rep axioms for 
a in E . Note that QR a can be written in the form 

(V res.a, y, z, s :: M(y,z,s) =>■ T.a(res.a, y)[s] = z } 
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for some suitable M and suitable list y of variables. For any abstract variable a , 
let QP a be the pointwise axiom for T.a in E . Note that QP a has the form 

(V res.a, res.a, y, z, s :: res.a[s] = res.a[s] A N(y,z,s) =>■ 
T.a{res.a, y)[s] = T. aire's. a, z)\s\ ) 

for some suitable N (essentially y[s] = z[s] ) and suitable lists of variables y and 
z . Therefore, QR a A QP a has the shape prescribed for the predicate Q in the 
Chain of Equalities Lemma (page 113). 
Here, let Q be the conjunction 

( /\a I aon E e :: QR a A QP a ) 

Note that Q has no free variables: it is a closed statement about the various ab- 
straction functions. Let R denote the conjuncts of 

BP E A Rep E A PW E a F E (p) 
that are not in Q . So, we have 

[Q A R = BP E A Rep E A PW E A F E (p)] (65) 
Also, for any abstract variable a , let Q' a be the conjunction 

(/\b \ bon E s A a # b :: QR b A QP h ) 
So, we have for any a , 

[Q - QR a a QP a a Q'J (66) 

Let xx denote the list consisting of e and the residue variable res.a for each 
a such that a on £ s , and let yy denote the list of variables in zz but not in xx . 

For any sequence a of modifies lists in E , any x in xx , and any integer k , 
we define chain' x (a, k) to be the conjunction 

{ f\v \ v £ xx A x v :: chain v (a, k) ) 

where chain is defined as in the setting of the Chain Rewriting Lemma (page 122). 
So, we have for any x in xx and any a and k , 

[chain(a, k) = chain x (a, k) A chain' x (a, k)] (67) 

We calculate, 
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[BP E A Rep E A PW E a F E {p) => (Vzz :: zz = zz => 
ulp E (C, (Vzz :: zz = zz =>• mcr E {w) }) } ] 
{ (65) } 
[2 A R => (Vzz :: zz = zz => 

ulp E (C, (Vzz :: zz = zz =>• mcr E {w) }) } ] 
{ predicate calculus, since Q and 7? have no free occurrences 
of zz } 

[Q A R A zz = zz => ulp E (C, (Vzz :: zz = zz =>■ mcr E (w) }) ] 

{ rename zz, zz to fresh zzo, zzi , using the fact that Q has no free 
variables; and zz = (.a;, yy) } 
[2 A i?(zz, zz := zzo, zzi) a xx 0 = xx\ A yy 0 = yy\ =>• 

ulp E (C, (Vzz :: zz = zz =>• mcr E {w) })(zz, zz := zzo, zzi) ] 
{ let T abbreviate R(zz, zz := zz 0 , ZZ\) A yy 0 = yy l , 
and definition of chain (page A23) for any list a } 
[Q A T A chain(a, 0) =>• 

ulp E (C, (Vzz :: zz = zz =>■ mcr E {w) ))(zz, zz := zzo, zzi) ] 
{ Chain Rewriting Lemma with 

Q, k, 6 := Q A T, 0, (zz, zz := zz 0 , zzi) } 
[Q A T A P A chain(B,t) =>• (Vzz :: zz = zz =>• mcr E (w) ) a ] 

{ rewrite quantification as a substitution } 
[2 A r A P A chain(Ji,l) mcr E (w)(zz := zz) a ] 

{ (63): mcr £ , and predicate calculus, leaving the range of a 
implicit } 
(/\a :: [Q A r A P A chain{fi,l) => 

modcon E (w, res. a, res.a)(zz '■= zz) cr ] ) 
{ modcon E , using a fresh t } 
(A« " [Q A r A P A chain{fi,l) => 
(V? :: res\a[/] = res.a[t] v 

modpoint E (res.a, w, t) )(zz := zz) c ] } 
{ predicate calculus, since ? does not occur free in antecedent } 
(/\« " [2 A T A P A chain{fi,l) A 

-^modpoint E (res .a, w, t)(zz := zz)cr =>• 
(res.a|>] = res.a[t])(zz := zz) a ] } 
{ o is an £ -replacement, and let t abbreviate (zz := zz) cr } 
( f\a :: [Q A T A P A chain(fi,i) A -<modpoint E (res.a,w,t)r =>• 
res.a_2i[t] = res.a M+1 [t] ] ) 
{ (66) and (67) } 
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(Afl " [Q R a ^ QPa A Q' a A T A P A chain res . a {ft,l) A 
chain' resa (ft , I) A -<modpoint E (res.a,w,t)x =>■ 
res.a- U [t\ = res.a M+1 [t] ] } 
= { Chain of Equalities Lemma, since Q' a , T, P, chain' resa (ft, £) , 

-^modpoint E (res .a, w,t)x, and the Kj 's in chain' res a (ft, 1) are 
almost independent of res.a with respect to T.a } 
( A a - [<2^ A QP a A Q' a A T A P A chain res . a (ft, I) A 
chain' res a (ft, 1) A -<modpoint E (res.a,w,t)x =>• 

(Ail -2£<7<3£ + l :: -<Kj(res.a, ft,t) )]) 
= { (66), (67), and predicate calculus, henceforth leaving the range of j 

implicit } 
{ /\a :: [Q A T A P A chain{ft,l) 

modpointE(res.a, w,t)r v ( A J :: ~^Kj(res.a, ft, t) ) ] } 
=>■ {by (64), [modpoint E (res.a, w,t) =>• modpoint E (s, w,t)] } 

(A« - [2 a T A P A chain(ft,l) => 

modpoint E (s, w,t)x v ( A J :: ~ , Kj{res.a, ft, t) ) ] ) 
= { predicate calculus } 

[2 A r A P A chain{ft,l) => 

modpoint E (s,w, t) x v ( Ai :: (A a :: ~'Kj(res.a, ft, t) )) ] 
= {by (64), the definition of ^ , and DeMorgan's law, we have 

[<A«" ^Kj(res.a,p,t)) = ^Kj(e,ft,t)] } 
[Q A T A P A chain(ft,i) => 

modpoint E (s, w,t)x v ( Ai :: "'Kjie, ft,t) } ] 
=>• { instantiating the quantifications in chain £ ( ft, I) with s := ? yields 

(Ai " £,W = £;+i W v 0 } } 

[Q A T A P A chain{ft,l) => 

modpoint E (s, w,t)x v ( Ai :: £/M = £y+iM ) ] 
=>• { transitivity of = } 

[Q A T A P A chain{ft,l) => 

modpoint E (s, w,t)x v e_2fW = £3^+1 M ] 
= { predicate calculus, since t does not occur free in antecedent; 

and x = (zz := zz) a where a is an £ -replacement } 
[Q A T A P A chain{ft,i) => 

( W :: modpoint E (s, w, t) v e|>] = e|>] } r ] 
= { modcon E ; and r , substitution, and quantification } 
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[Q A T A P A chain{fi,l) => 

(Vzz :: zz = zz =>■ modcon E (w, e,e))cr] 
= { Chain Rewriting Lemma with the same C , a , k , and 0 as before, 

but with R := (Vzz :: zz = zz =>• modcon E (w, s, s) ) } 
[Q A T A chain(a, 0) =>• 

ulp E (C, {V zz :: zz = zz =>■ modcon E (w, e, s) ))(zz, zz := zzo, zzi) ] 
= { T, chain(a, 0) , yy, xjc } 

[2 a 7?(zz, zz := zzo, zz\) a zzq = zz\ =>■ 

ulp E (C, ( Vzz :: zz = zz =>■ modcon E (w, e, s) >)(zz, zz := zzo, zzi) ] 
=>• { rename zzo, zzi back to zz, zz, since zz 0 , zzi were chosen to be 

fresh } 
[Q A R A zz = ZZ =r- 

ulp E (C, (Vzz :: zz = zz =>■ modcon E (w, s, s) }) ] 
= { predicate calculus, since Q has no free variables and R has no free 

occurrences of zz } 
[Q A R => (Vzz :: zz = zz => 

ulp E (C, (Vzz :: zz = zz =>■ modcon E (w, e, s) >) > ] 
{ (65) } 

A flep £ A Z 5 ^ A F £ (p) => (Vzz :: zz = zz => 
ulp E (C, (Vzz :: zz = zz =>■ modcon E (w, s, s) >) ) ] 

With that, we have proved the Chain of Equalities Corollary. b 



A24 Refunctionalization 

The formula VCo(m, C) has been generated using declarations in D . How do 
we get from it to VC E (m, C) , that is, how can we even begin to relate VC D (m, C) 
to VC E (m, C) ? For example, an occurrence of a variable a that depends on s in 
E will be functionalized in VC E to an expression of the form T.a{. . . , e) ; while 
in VC D the corresponding occurrence of a will be functionalized to T.a{. . .) . 
We deal with these kinds of discrepancies by refunctionalizing VC D (m, C) into a 
formula that looks closer to VC E (m,C) than VC D (m,C) does. Refunctionaliza- 
tion is driven by the syntactic form of the given formula. Here is where it will be 
useful that we left some markers in the VC generated by VC D (m, C) , to give us 
guidance in refunctionalization. 

We introduce refunctionalization as a meta function X D E : if Q is a vanilla 
expression in D , then X D E (Q) approximates a vanilla expression in E . To have 
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mercy on our readers, and on ourselves, we drop the subscripts of X and will 
write simply X for X DE from now on. 

For any D, s , and E such that Extend(D, e,E) (defined in Section A16), 
we define X in Figure 17. The definition follows the cases in the grammar for 
vanilla expressions in Section A12, but with more special cases added. Since 
scalars (line 0) and concrete fields (line 1) are unchanged by functionalization, 
they are also unchanged by refunctionalization. An abstract variable a (line 2) 
with one direct dependency, say / , in D and one additional dependency, e , in 
E is refunctionalized by recursively refunctionalizing the arguments to T.a (the 
residue arguments remain unchanged) and adding e as an extra argument adorned 
in the same way as the residue arguments. Since the argument order of an abstrac- 
tion function is arbitrary, we order s last among a 's dependencies. Cases where 
the abstract variable has different numbers of dependencies are straightforward 
and omitted from Figure 17 (for example, if a does not depend on « in £, then 
refunctionalization does not add the extra argument s ). 

X distributes over operators. Line 3 shows the equation for an arbitrary binary 
operator; operators with other arities are similar. Except as stated below, X also 
distributes over quantifications over scalars (line 4), concrete fields (line 5), and in- 
dividual residue variables, with (line 8) and without (line 6) equality antecedents. 
Quantifications over s and equality antecedents for s are introduced during the 
refunctionalization of quantifications over shared residues (lines 7 and 9). 

For quantifications arising from individual-residue modification constraints 
(line 10), X applies recursively to the subpredicate Q. Shared-residue mod- 
ification constraints (line 11) are similar, but in this case, X also introduces 
a special modification constraint for s , namely modcon E (w, s, sres) , where w 
comes from the marker "w" around the given modification constraint for sres . 
Note that the second and third parameters to this use of modcon E are different, 
whereas they always coincide when modcon E is generated in a VC. (The rea- 
son for the special modification constraint is as follows. In order to prove that X 
preserves the validity of VCs, see (75), refunctionalization must add some modi- 
fication constraint for s . In the main proof of Soundness Lemma C, we will get 
the desired modcon E (w, e, s) by applying the Chain of Equalities Corollary. At 
that time, modcon E (w, e, sres) is absorbed, because it turns out to be weaker than 
modcon E (w, s, s) .) 

Refunctionalization simply replaces the pointwise axioms (line 12) and rep 
axioms (line 13) generated in D by those that would be generated in E . 
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10 : 
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X(s) 
X(c) 

X^.aisfes, res.a, 0) 
X(Q0 op 21) 
X((Ws :: Q)) 
X((W~c :: Q)) 
X({W res.a :: Q }) 



s 
c 



Q)) 

: res.a 
sfes = 



13 



T.a{sfes, res.a, X(Q), s) 
= X(Q0)oy>X(Q1) 
= (Vs :: X(0) 
= (V? :: X(Q)> 
= (VreS.a :: X(Q) } 
= (We :: (V sfes :: X(Q) )} 
= res.a ^ Q)) = 

(W res.a :: res.a = res.a =>• X(0 ) 
sres =>• <2 )) = 
(Ve :: s = s =>• (W sfes :: sfes = sfes =>• X(0 )) 
res.als] = res.a[s] v 2 }) = 

w:(Vs :: res.a[s] = res.a[s] v X(0 }) 
sfes[s] = sres!*] v Q }) = 

w:( Vs :: sfes[s] = sfes[s] v X(0 }) A 
modcon E (w, s, sres) 
( V t, sres, sfes, res.a, res.a, f,f, s, s :: 
sfes[t] = sres!/] A 
res.a[t] = res.a[t] A 

ht]=ht] a m = m => 

T.a{sfes, res.a, f, s)[t] = 
T.a(sfes, res.a, f, s)[t] } 
X((Wt: T, sres, res.a, f :: t nil =>• T.a{sres, res.a, f)[t] = e )) = 

(W f.T, sres, res.a, f, s :: ? 7^ nil =>• T.a{sres, res.a, f, s)[t] = e } 



X((Wsfes : 
X({Wre~s.a 

X((Wsfes : 

X(w:{Ws :: 

X(w:{Ws :: 



12 : X( formula (25), page 84 ) 



Figure 17: The definition of the refunctionalization meta function X . 
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A25 Properties of X 



The refunctionalization meta function X enjoys several distributive and commu- 
tative properties. We list these properties in this section for use in the main proof 
of Soundness Lemma C. After we give the main proof in the next section, we will 
spend a number of sections giving the proofs of the properties listed here. 

The properties in this section are stated in the context of any D , s , and E 
that satisfy Extend(D, s, E) . 

For any user expression e in D , 

X{F D (e)) = F E (e) (68) 
For the background predicate, rep axioms, and pointwise axioms, 

[X(BP D ) <= BP E ] (69) 

X(Rep D ) = Rep E (70) 

X(PW D ) = PW E (71) 

For any modifies list w in D, 

[X(mc D (w)) A modcon E (w, s, s) = mc E (w)] (72) 
[X(me D (w)) mcr E (w)] (73) 

where mcr E is the meta function defined by (63) on page 127. For any command 
C in D and any predicate Q in D , 

[X(wlp D (C,Q)) => wlp E (C,X(Q))] (74) 

For any implementation C in D of a method m , 

[VC D (m,Q] => [X(VC D (m, C))] (75) 

Properties (69) through (74) essentially say that meta function X refunction- 
alizes formulas in the way we intended, that is, that X transforms a VC generated 
in D into a formula quite similar to the VC that would have been generated in E 
(the only differences are that X doesn't conjoin the background-predicate axioms 
that are generated only in E and that X introduces modcon E (w, s, sres) instead 
of the proper modification constraint modcon E (w, s, e) ). 

Property (75), which states that X preserves the validity of VCs, plays a vital 
role in our proof of the Soundness Theorem. The essence of the Soundness The- 
orem is captured by Soundness Lemma C, and at the heart of its proof are two 
pieces: the Chain of Equalities Corollary and X property (75). 
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A26 The main proof of Soundness Lemma C 

Using the yet-to-be-proved properties of X stated in the previous section, we give 
the proof of Soundness Lemma C. 

Proof of Soundness Lemma C. Let D, s , E, m, and C satisfy the antecedent 
of Soundness Lemma C. Let zz be the concrete fields and residue variables in D , 
and suppose the specification for m is 

requires p modifies w ensures q 

We calculate, 

[VC D (m, Q] 

=>- { (75): X preserves the validity of VCs } 

[X(VC D (m, O)] 
{ VC D } 

[X(BP D A Rep D A PW D A F D (p) => (Vzz :: zz = zz => 

wlp D (C, (Vzz :: zz = zz =>• FdO?) a mc D (w) )) )] 
= { definition of X on operators =>• and A } 

A X(flep D ) A X(PW D ) A X(F D (p)) => 
X(( Viz :: zz = zz =>■ 

wlp D (C, (Vzz :: zz = zz =>• F^O?) A mcz)(w) }) })] 
=> { (69): X and } 

A X(flep D ) A X(PW D ) A X(F D (p)) => 
X(( Vzz :: zz = zz =>■ 

wlp D (C, (Vzz :: zz = zz =>• F^O?) a mc D (w) )) })] 
{ (70) and (71) and (68): X , tfep , PW , and F } 
[BP E A Rep E A PW E A F E (p) => 
X(( Vzz :: zz = zz =>• 

wlp D {C, (Vzz :: zz = zz =>• F D 0?) A mc D (w) )) })] 

{ X } 

[BP E A Rep E a PW E a F E (p) => (Vzz, e :: zz = zz a e = s => 
X(wlp D (C, (Vzz :: zz = zz => Fd(g) a mc D (w) })) }] 
=> { (74): X and w/p } 

A Rep E a PW E a F E (p) => (Vzz, e :: zz = zz a e = e => 
w//7 £ (C,Z((Vzz :: zz = zz Fd(q) a mc 0 (w))))>] 
{ X } 
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[BP E A Rep E a PW E a F E (p) => (Vzz, £ :: zz = zz a e = s 

wlp E (C, (Vzz, £ :: zz = zz A £ = e =>• X(F D (q) A mc D (w)) }) )] 
= { definition of X on A , and (68) } 

[BP E A Rep E A PW E A F E (p) =^ (Vzz, £ :: zz = zz a £ = e =^ 
wlp E (C, (Vzz, £ :: zz = zz A s = e =>• F £ (g) A X(mc D (w)) }) }] 
= { (38): monotonicity of wlp E , since by (73), 

[F E (q) A X(mc D (w)) =>• mcr £ (w)] } 
[BP E A Rep E A PW E A F E {p) =^ (Vzz, e :: zz = zz a e = s => 

wlp E (C, (Vzz, e :: zz = zz A e = e =>• F £ (g) A X(mc D (w)) )) }] A 

A 7?ep £ A PW £ A F £ (/?) =^ (Vzz, e :: zz = zz a s = s => 
wlp E (C, (Vzz, £ :: zz = zz A s = s =>• mcr £ (wO }) }] 
=>• { (36): w/pa implies } 

A Rep E A PW E A F E (p) =^ (Vzz, £ :: zz = zz a £ = s 
wlp E (C, (Vzz, £ :: zz = zz A s = s =>• F £ (g) A X(mc D (w)) }) }] A 
[BP E A Rep E a PW E A F E (p) =^ (Vzz, £ :: zz = zz a £ = s 
ulp E (C, (Vzz, £ :: zz = zz A s = s =>• mcr £ (w) )) }] 
=>• { Chain of Equalities Corollary (page 127) with zz := (zz, £) } 

[BP E A Rep E A PW E A F E (p) =^ (Vzz, £ :: zz = zz a s = s 

wlp E (C, (Vzz, £ :: z'z = zz A s = s =>• F £ (g) A X(mc D (w)) )) }] A 

A 7?ep £ A PW £ A F £ (/?) =^ (Vzz, £ :: zz = zz a £ = £ 
ulp E (C, (Vzz, £ :: zz = zz A e = s =>• modcon E (w, s, e) }) }] 
= { (39): conjunctivity, , and w//?£ } 

A Rep E A PW E A F E (p) =^ (Vzz, £ :: zz = zz a £ = £ =>■ 
wlp E (C, (Vzz, £ :: zz = zz A e = e =>• 

^bO?) A X(mc D (w)) A modcon E (w, s, s) }) }] 
= { (72): X and modification constraints } 

[BP E A Rep E A PW E A F E (p) => (Vzz, £ :: zz = zz a s = s => 
wlp E (C, (Vzz, £ :: zz = zz A e = e =>• F £ (g) A mc £ (w) }) )] 
= { VC £ , since zz , s are the concrete fields and residue variables 

in E } 

[VC £ (m, Q] □ 



Now, all that remains is proving the eight properties of X . 
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All X and user expressions 



In this section, we prove X property (68): for any D , e , and E such that 
Extend(D, s, E) and any user expression e , 

X(F D (e)) = F E (e) 

Proof of (68). We actually prove this property not just for user expressions, but 
for any expression e in the domain of F D except residue variables. The proof is 
by induction over the shape of e . 

Case s: 

X(F D (s)) 

{ Fd and X } 

= { Fe } 

Fe(s) 

Case c: 

X(F D (c)) 

{ Fd and X } 

= { ^ } 

Case a: 

{ Fd } 
X^.aisfes, res.a, F D (f))) 

{ * ) 
T.a{sres, res.a, X(F D (f)), s) 
= { induction hypothesis } 

T.a{sres, res.a, F E (f), s) 
= { F E on concrete field e } 

T.a{sres, res.a, F E (f), F E (s)) 

{ F E } 
F E (a) 
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Case eOopel : 

X(F D (eOopel)) 

{ F D } 
X(F D (eO)o V F D (el)) 

{ X } 
X(F D (eO))opX(F D (el)) 
= { induction hypothesis, twice } 

F E (eO)ovF E (el) 

{ F E } 
F E (eOop el) 

Case (Vs :: e } : 

X(F D ((Vs :: e ») 

{ ^ } 
X«Vs :: 

{ ^ } 
(Vj :: X(F D (e))> 
= { induction hypothesis } 

(V s :: F E (e) } 

{ } 
F £ ((V5 :: g» 

That concludes the proof of property (68). m 



A28 X and the background predicate 

In this section, we prove X property (69): for any D , s , and E such that 
Extend (D, e,E), 

[X(BP D ) <= fl/> £ ] 

Proof of ( 69). Since the background predicate ,RP D is generated as a function of 
the type declarations in D , independent of what other declarations D contains, 
it follows that BP D does not mention abstraction functions, residue variables, 
residue modification constraints, pointwise axioms, or rep axioms. Thus, we have 

X(BP D ) = BP D 

We calculate, 
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X(BP D ) 

{ observation above } 

BP D 

{ D c E , which follows from Extend{D, s, E) , and (26) } 

BP E 



A29 X and rep and pointwise axioms 

In this section, we prove X properties (70) and (71): for any D, s , and E such 
that Extend (D, s,E), 

X(Rep D ) = Rep E and 
X(PW D ) = PW E 



Proof of (70) and (71). Let D, e, and E satisfy Extend(D, s, E) . By the 
definition of X , the refunctionalization of any pointwise axiom or rep axiom in D 
equals the corresponding axiom in E . Since D and E coincide in their abstract 
field and rep declarations, (70) and (71) follow. □ 



A30 X and modification constraints 

In this section, we prove properties (72) and (73), which relate X and modification 
constraints. We start by proving a three-part lemma that will be useful in the 
proofs of these properties. 

Lemma. For any D , e , and E such that Extend (D, s, E) , any modifies list w 
in D , any field / in D , and any individual residue variable res.a in D , 

X(modcon D (w,f,f)) = modcon E (w,f,f) (76) 

X(modcon D (w, res.a, res.a)) = modcon E (w, res.a, res.a) (77) 

X(modcon D (w, sres, sres)) = _ 
modcon E (w, sres, sres) A modcon E (w, s, sres) 
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Proof. For any field / in D , we calculate, 

X (modcon d ( w , / , /) ) 
= { (24): definition of modcon D } 

X(w:{Vs :: F D (f[s] =f[s] v modpoint D (f,w, s)) » 
= { X on unary operator "w:" and on scalar quantification } 

w:(Vs :: X(F D (f[s] =f[s] V modpoint D (f,w,s)))) 
{ (68): XoF D = F E } 

w:(Vs :: F £ (/[5] =/[s] v modpoint D (f,w,s)) ) 
= { lemma (33) with x :=f } 

w:(Vs :: F E (f[s] =f[s] v modpointE(f,w,s)) ) 
= { (24): definition of modcon E } 

modcon E (w,f,f) 

For any individual residue variable res. a , we calculate, 

X(modcon D (w, res.a, res.a)) 
= { (24): definition of modcon D } 

X(w:(V s :: F D (res.a[s] = res.a[s] v modpoint D (res.a,w, s)) )) 
{ F D }^ 

X(w:(V s :: res.a[s] = res.a[s] v F D (modpoint D (res.a,w, s)) )) 
= { X on individual-residue modification constraint } 

w:(Vs :: res.a[s] = res.a[s] v X{F D (modpointD(res.a,w, s))) ) 
' { (68): XoF D = F E } 

w:(V5 :: res .a[s] = res .a[s] v F E (modpoint D (res.a,w,s))) 
= { lemma (33) with x := res.a } 

w:(V5 :: res.a[s] = res.a[s] v F E (modpoint E (res.a,w,s))) 
= " { F £ } 

w:(V5 :: ^(reJ.af*] = rei.a[5] v modpoint E (res.a,w,s))) 
= { (24): definition of modcon E } 

modcon E (w, res.a, res.a) 

For the shared residue variable, we calculate, 

X(modcon D (w, sres, sres)) 
= { (24): definition of modcon D } 

X(w:{Vs :: F D (sres[s] = sres[s] v modpoint D (sres,w, s)) }) 
{ F D }^ 

Z(w:(V5 :: sres[s] = sres[s] v F D (modpointD(sres,w,s)))) 
= { X on shared-residue modification constraint } 
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w:(V s :: sres[s] = sres[s] v X(F D (modpointD(sres,w,s))) ) A 
modcoriE(w, e, sres) 

{ (68): XoF D =F E } 
w:{V s :: sresls] = sresls] v F E (modpoint D (sres,w, s)) ) A 
modcon E (w , s, sres) 
= { lemma (33) with x := sres } 

w:{Vs :: sres^] = sres[s] v F E (modpoint E (sres,w, s)) ) A 
modcon E (w, s, sres) 

{ F E } 

w:(Vs :: F E (sres[s] = sres[s] v modpoint E (sres,w, s)) ) A 
modcon E (w, s, sres) 
= { (24): definition of modcon E } 

modcon E (w, sres, sres) A modcon E (w, s, sres) 

That proves the three parts of the lemma. m 

Now for the proof of X property (72): for any D , e , and E such that 
Extend (D, s, E) and any modifies list w in D, 

[X(mc D (w)) A modcon E (w, s, s) = mc E (w)] 

Proof of (72). For any D , s , and E such that Extend(D, s, E) and any modifies 
list w in D,we calculate 

X{mcu{w)) A modcon E (w , s, e) 
= { mc D } 

X(( /\x | x £ D :: modcon D (w, x, x) )) A modcon E (w, s, s) 
= { definition of X on A } 

( /\x | x £ D :: X(modcon D (w , x, x)) ) A modcon E (w, s, s) 
= { split range: let / range over fields, let a range over abstract fields, 

and let (as usual) res.a denote the residue variable associated with 
a } 

( A/ I / e D :: X(modcon D (w,f,f)) ) A 

( f\a | a £ D :: X(modcon D (w , res.a, res.a)) ) A 

X{modconi)(w, sres, sres)) A modcon E (w, e, s) 

{ lemma (76)-(77)-(78) } 
( f\f | / g D :: modcon E (w,f,f) ) A 
( /\a | a £ D :: modcon E (w, res.a, res.a) ) A 
modcon E (w , sres, sres) A modcon E (w, s, sres) A modcon E (w , s, s) 
= { lemma (34): [modcon E (w, s, s) =^ modcon E (w , e, sres)] } 
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( A/ I / e D :: modcon E (w,f,f) } A 

(/\a | a € D :: modcoriE(w, res.a, res.a) ) A 

modcon E (w, sres, sres) A modcon E (w, s, s) 
= { combine ranges } 

( f\x | x £ E :: modcon E (w, x, x) ) 
= { mc E } 

mc E (w) □ 

And now the proof of X property (73): for any D, s, and E such that 
Extend (D, s, E) and any modifies list w in D, 

[X(mc D (w)) =>• mcr E (w)] 



Proof of (73). Let D , s , and £ satisfy Extend(D, e, E) , let w be any modifies 
list D , and let a by any abstract field in E such that a on E e . Since D and E 
coincide in their declarations of abstract fields, a is also in D . Let res.a denote 
the individual residue variable of a. Then, modcon E (w, res.a, res.a) denotes an 
arbitrary conjunct of mcr E (w) . We calculate, 

modcon E (w, res.a, res.a) 
{ lemma (77) } 

X(modcon D (w, res.a, res.a)) 
<^= { strengthening, since res.a e D } 

( f\x | x £ D :: X(modcon D (w , x, x)) ) 
= { definition of X on A } 

X({ f\x | x £ D :: modcon D (w,x,x) )) 
= { tnc D } 

X(mc D (w)) □ 



A31 X and wlp 

In this section, we prove X property (74): for any D , e , and E such that 
Extend (D, s, E) , any command C in D , and any predicate Q m D , 

[X(wlp D (C,Q)) => w/p £ (C,X(0)] 
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Proof of (74). Let D , e , and E satisfy Extend(D, s, E) , let C be a command 
in D , and let Q be a predicate in D . We proceed by induction over the shape of 
C. 

Case s := e : 

X(w/p D (s := g, 2)) 
= { w/p D } 

X((Vs' :: s' = Fj)(e) => (Vs :: 5 = 5' => 2)}) 
{ ^ } 

(Vs' :: s / = X(F D (e)) => (Vs :: 5 = 5' => X(0 » 

{ (68): XoF D =F E } 
( Vs' :: 5' = => (V* :: 5 = 5' => X(0 )} 

= { w//? E } 

w/p £ (s := e, X(0) 

Case c[<?0] := el : 

X(wlp D (c[eO] :=el,Q)) 
= { wlp D } 

X((Vc' :: c' = jtore(c, F^cO), => (Vc :: c = d => 2))) 

{ X } 

(Vc' :: c , = Jto7K(c,X(F D (cO)),X(F D (el))) => (Vc :: c = c' => X(Q) }} 
= { (68): XoF D =F £ , twice } 

(Vc' :: c' = store(c,F £ (eO),F £ (el)) => (Vc :: c = d => X(0 }} 
= { w/p E } 

w/p £ (c[eO] :=cl,X(0) 

Case assert e : 

X(wlp D (assert e,Q)) 
= { wlp D } 

X(F D (e) A Q) 

{ X on A , and (68): X o F D = F E } 
F E (e) a 

= { wlp E } 

(assert e, X(Q)) 
Case assume e : 
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X(wlp D (assume e, 0) 
= { wlp D } 

X(F D (e) => 0 

{ X on => , and (68): XoF D = F E } 

F E (e) => X(0 
= { w/p £ } 

w/p £ (assume e, X(0) 

Case CO ; CI : 

X(wlp D (C0 ; CI, 0) 

= { wlp D } 

X(w/p D (C0, w/^dCCI, 0)) 
=>■ { induction hypothesis } 

wlp E (CO,X(wlp D (C\,Q))) 
=>■ { induction hypothesis, since (38): wlp E is monotonic } 

wlp E (CO,wlp E (Cl,X(Q))) 
= { wlp E } 

wlp E (CO;Cl,X(Q)) 

Case CO D CI : 

X(wlp D (C0 D C1,0) 
= { wlp D } 

X(wlp D (C0, 0 A wlp D (Cl, 0) 
{ X on A } 

X(w/p D (C0, 0) A X(wlp D (Cl,Q)) 
=>• { induction hypothesis, twice } 

wlp E (C0,X(Q)) A wlp E (Cl,X(Q)) 
= { wlp E } 

wlp E (C0 D C1,X(0) 

Case var s in C end : 

X(wlp D (\ar s in C end, 2)) 

= { } 

X«Vs :: wlp D (C,Q) » 
{ X } 

(Vs :: X{wlp D (C,Q) » 
=>■ { induction hypothesis } 
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(Vs :: wlp E (C,X(Q))} 

= { wlp E } 

wlp E (ynr s in C end, X(Q)) 

CASE call m(e) : Suppose the specification of m , after renaming its parameter to 
a fresh dummy t,is 

method m(t: T) requires p modifies w ensures q 

and let zz denote the list of concrete fields and residue variables in D . Then, 

X(wlp D (caUm(e), 0) 
= { wlp D } 

X((Vf :: t = F D (e) => F D (p) A (Vzz :: zz = zz => 
(Vzz :: zz = zz =>• (Vzz :: F D (q) A mc D (w) =>• 

(Vzz :: zz = zz => (Vzz :: zz = zz => 2))))))) 
{ X } 

(Vf :: ? = X(F D (e)) => X{F D (p)) A (Vzz,e :: zz = zz a e = e => 
(Vzz, e :: zz = zz a e = £ =>• (Vzz, e :: X(F D (q)) A X(mc D (w)) =>• 
(Vzz, £ :: zz = zz a e = e =>• (Vzz, £ :: zz = zz A e = e =>• 
X(0 )}}}}} 

= { (68): X o F D = F E , three times } 

(V?:: t = F E (e) => F £ (p) A (Vzz, £ :: zz = zz a e = e => 

(Vzz, £ :: zz = zz a s = s =>• (Vzz, £ :: A X(mc D (w)) =>• 

(Vzz, e :: zz = zz a e = e =>• (Vzz, £ :: zz = zz A 8 = 8 =>• 
*(0 )))))) 

=> { by (72), [X(wc D (w)) 4= wc E (w)] } 

(V? :: ? = F E (e) => A (Vzz, £ :: zz = zz a e = e => 

(Vzz, £ :: zz = zz A e = e =>• (Vzz, £ :: a mc £ (w) =>• 

(Vzz, £ :: zz = zz a e = e =>• (Vzz, £ :: zz = zz a 8 = 8 =>• 
X(0 )})}}} 

= { w/p E , since zz , £ are the concrete fields and residue variables 

in E } 

w/p £ (caUm(e),Z(0) □ 

A32 X and VC 

We now have only one property left to prove to complete the proof of Soundness 
Lemma C and thus the Soundness Theorem, namely X property (75): for any 
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D , s , and E such that Extend (D, s, E) and any implementation C in D of a 
method m, 

[VC D (m,Q] [X(VCz>(m, C))] 

Proof of (75 ). The proof consists of a number of steps that transform the syntactic 
expression Q into the syntactic expression X(Q) , preserving the validity of the 
original Q. This technique is the same as we used in Section A16, where we 
proved Soundness Lemma D from Soundness Lemma C, but the steps here will 
be different. 

For use in the proof, we define three functions, " ( , ) ", car , and cdr , which 
satisfy the following properties: 

( V a,b, c, d :: {a, b) = (c , d) = a = c A b = d ) (79) 

(V/?, a, b :: p = (a, b) = a = car(p) A b = cdrip) ) (80) 

(Va,b,t :: (a,b)[t] = (a\f\,b\f\)) (81) 

(Readers who doubt that such properties can be postulated in this soundness proof 
are encouraged to consult Part IV of this appendix.) 

From the definition of X (Figure 17, page 134), we can see the syntactic dif- 
ferences between VC D (m, C) and X(VC D (m, C)) . These differences are shown 
side by side in Figure 18. In that figure, a is an abstract variable in D that de- 
pends on £ in £. 

The idea is to transform the formula VC D (m, C) into X(VC D (m, C)) , pre- 
serving validity. We do so by a series of transformations to the working formula, 
which starts off as VC D (m, C) and ends up as X(VC D (m, C)) . Our series of 
transformations are guided by the differences shown in Figure 18. 

So, initially, our working formula contains subexpressions of the forms sug- 
gested by Figure 19. In that figure, a takes the role of a typical abstract variable 
that depends on « in £, and b takes the role of a typical abstract variable that 
does not depend on e . 

Step 0: From Figure 19 to Figure 20. We start by reconciling an easy differ- 
ence: Dl. For each formula of the form (shown in the left column in Figure 18 
under the label) Dl in the working formula, we insert a surrounding quantification 
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VC D (m, C) 



X(VC D (m, O) 



,~s) 



DO. Functionalized forms: 

T.a{sfes, . . .) T.a{sfes, 
Dl. Quantifications over shared residues: 

( V sres ::...) ( Ve :: ( V sfes :: . . . )} 

D2. Quantifications over shared residues with equality antecedents: 

(V sfes :: sfes = sfes =>•...) ( Ve :: £ = e =>• 

( V sfes :: sres = sfes =>• . . . }} 
D3. Shared-residue modification constraints: 



w:(Vs :: jres[s] = sresls] w:(Vs 

v...} 
D4. Pointwise axioms: 
( V t, sres, sfes, ... :: 
sres[t] = sfes[t] A . . . =>• 
T.a{sfes, . . .)[t] = 
T.a(sfes, . . .)[t] ) 
D5. Rep axioms: 
{Vt:T,sres, . . . :: t # nil => (Vt:T,sres, 
T.a(sres, . ..)[{] = e) T.a(sres, . 



sfes\s\ = sfes[s] 
v . . . } A modcon E (w, s, sres) 



{V t, sres, sfes, ...,£, e :: 
sres!/] = sres|>] A ... A e[?] = e[f] 
T.a{sfes, . . . , s)[t] = 
T.a(sfes, . . . , s)[t] ) 



.,e :: t # nil 

, s)[t] = e ) 



Figure 18: A diagram showing the syntactic differences between VC D (m, C) and 
X(VC D (m, O) . 

DO: T.a{sfes, . . .) 

T.b{sfes, . . .) 
Dl: (Vra :: ... } 
D2: (V sfes :: sres = sres =>■ . . . ) 
D3: w:(Vs :: sres[s] = sres[s] V ...) 
D4: (V t, sres, sfes, .. . :: sfes[t] = sfes[t] A . . . =>• 
J-'.aisfes, . . .)[t] = T.a{sfes, . . .)[t] ) 

(V t, sres, sfes, .. . :: sfes[t] = sfes[t] A . . . =>• 
T.b(sfes, . . .)[t] = T.b(sfes, . . .)[t] } 
D5: {Vt:T,sres, . . . :: ? # nil =>• T.a{sres, ...)[?]= e ) 

( V/: 7, sres, ...::?# nil =>• T.b(sres, . . .)[t] = e } 



Figure 19: A sketch of the initial working formula. 
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DO: T.aisres, . . .) 

T.b{sfes, . . .) 
Dl: (Ve :: {"i sres :: ... }} 
D2: (V sfes :: sfes = sfes =>• ...} 
D3: w:(Vs :: sfes[s] = sfes[s] V ...) 
D4: (V t, sres, sres, .. . :: sres[t] = sres[t] A . . . =>• 
T.a(sfes, . . .)[t] = T.a{sres, . . .)[t] ) 

(V t, sres, sres, .. . :: sres[t] = sres[t] A ... =>• 
T.b(sres, . . .)[t] = T.b(sres, . . .)[t] } 
D5: {Vt:T,sres, ... :: t # nil =>- F.a(sres, ...)[t\ = e ) 

( V?: 7, sra, ... :: ? # nil =>- T.bisres, ...)[?] = e > 

Figure 20: A sketch of the working formula after transforming it to reconcile the 
Dl differences. 

over e . The fact that this transformation preserves the validity of the working for- 
mula is justified by the following fact: if R is a predicate with no free occurrences 
of s , then 

[R = (Ve :: R}] 

In Figure 19, the working formula has no free occurrences of s and inserting 
quantifications over e as suggested does not introduce any free occurrences of s , 
so this transformation can be done one place at a time, in any order. After the 
transformation, the working formula has the shape suggested by Figure 20. 

Step 1: From Figure 20 to Figure 21. Differences of the form described by D2 
between the formulas VC D (m, C) and X(VC D (m, C)) are also easy to reconcile 
in the working formula. First, we insert quantifications over e as needed, like we 
did in the previous transformation. Then, we insert the antecedent " e = e " in 
these places. Since the subexpressions of the form D2 appear only in positive posi- 
tions (by characteristic VI, page 87), inserting these antecedents will only weaken 
the working formula, hence preserving its validity. After this transformation, the 
working formula has the shape suggested by Figure 21. 

Step 2: From Figure 21 to Figure 22. To transform the working formula fur- 
ther, we need to tackle the problem that the arity of abstraction function T.a is 
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DO: T.a(sfes, . . .) 

T.b(sfes, . . .) 
Dl: (We :: (V sfes :: ... }} 

D2: (We :: e = e =>• (Wsfes :: sfes = sfes =>• . . . }) 
D3: w:(Vs :: smsls] = sresls] V ...) 
D4: (V t, sres, sres, .. . :: sres[t] = sres[t] A . . . =>• 
T.a(sfes, . . .)[t] = T.a(sfes, . . .)[t] ) 
(V t, sres, sres, .. . :: sres[t] = sres[t] A . . . =>• 
T.b(sfes, . . .)[t] = T.b(sres, . . .)[t] } 
D5: (Wf.T, sres, nil =>• T.aisres, . . .)[t] = e } 

(V/: 7, 5re5, ^ nil =>• T.b(sres, . . .)[t] = e ) 

Figure 21: A sketch of the working formula after transforming it also to reconcile 
the D2 differences. 

different in D than in E . In particular, the arity of T.a in the current working 
formula is one less than the arity of T.a in X(VC D (m, Q) . To reconcile this 
difference, we will substitute a new function for T.a , similar to what we did in 
Section A 16, but here we must first worry about getting the appropriate extra argu- 
ment, namely various bindings of e , in place. To that end, we start by performing 
the transformation justified by the following calculation: 

(Wsfes :: R ) 
=>• { instantiate sfes } 

( V sfes :: R(sfes := (sfes, e)) ) 

We perform this transformation at each place in the working formula where there's 
a quantification over sfes , except in pointwise axioms and rep axioms. The trans- 
formation preserves the validity of the working formula, since the affected quan- 
tifications occur in positive positions (by characteristic VI). The transformation 
yields a working formula whose shape is suggested by Figure 22. Note that this 
transformation does not change occurrences of sres bound to the quantifications 
in pointwise axioms and rep axioms. Note also that the transformation does alter 
occurrences of sres that appear in equality antecedents and in residue modifica- 
tion constraints, as shown in the figure. 

Step 3: From Figure 22 to Figure 23. Let's clean up the equality antecedents 
right away. We apply the following calculation to all sfes quantifications with 
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DO: F.a((sfes, e), . . .) 

T.b((sfes, e), . . .) 
Dl: (Ve :: (Vsfes :: . . . }} 

D2: (V? :: e = e =>• (W sfes :: (sres, e) = (sres, e) =>• ...}) 
D3: w:( W s :: (sfes, s)[s] = (sfes, e)[s] V . . . ) 
D4: (W t, sres, sres, .. . :: sres!/] = sres[£] A . . . =>• 
F.aisres, . . .)[t] = T.a(sfes, . . .)[t] ) 
(V t, sres, sres, .. . :: sres[t] = sres[t] A . . . =>• 
T.bisfes, . . .)[t] = T.b(sres, . . .)[t] } 
D5: ( Wt: T, sres, . . . :: t # nil =>• F.a(sres, . . .)[t] = e ) 
( V/: 7, 5re5, ... :: ? # nil =>- T.b{sres, ...)[t\=e) 

Figure 22: A sketch of the working formula after substituting the pair (sfes, s) 
for occurrences of sfes in the formula sketched in Figure 21. This transformation 
affects DO, D2, and D3. 

equality antecedents in the working formula: 

(Ve :: s = e =>• (W sfes :: (sres, e) = (5re5, e) =>• <2 >) 
= { (79): pairing and equality } 

(Ve :: s = e =>• ( V sfes :: sfes = sfes A s = e =>• 2 )) 
= { predicate calculus } 

(Ve :: e = e =>• (W sfes :: jra = sras =4> 2 }} 

Now we are ready to replace abstraction functions with new ones whose ar- 
ity is one larger. Let Q denote the current working formula. For each abstract 
variable a that depends on £ in £ (and as usual, we show the case where a has 
exactly one dependency, / , in D ), we perform the following steps: 

[Q] 

=>■ { instantiate the universally quantified T.a } 

\Q{T.a := (kp, res.a,f :: T.a{car{p), res.a,f, cdr(p)) })] 

And for each abstract variable b that does not depend on £ in £ (and as usual, 
we show the case where b has exactly one dependency, g, in D), we perform 
the following steps: 

[Q] 

{ instantiate the universally quantified T.b } 
\Q{T.b := (kp, res.b, g :: T.b(car(p), res.b, g) })] 
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DO: T.a(sfes, ...,£) 

T.b(sfes, . . .) 
Dl: (Ve :: (V sfes :: ... }} 

D2: (V? :: s = s =>• ( V sfes :: sfes = sfes =>• . . . }) 
D3: w:{Vs :: (sfes, e)[s] = (sfes, s)[s] v ...) 
D4: (y t, sfes, sfes, .. . :: sres[£] = sres!/] A . . . =>• 

T.a(car(sfes) , . . . , cdr(sfes))[t] = T.a(car(sfes), . . . , cdr(sfes))[t] ) 
(V t, sfes, sfes, .. . :: sfes[t] = sfes[t] A . . . =>• 
T.b(car(sfes), . . .)[t] = T.b(car(sfes), . . .)[t] ) 
D5: (V t.T, sres, . . . :: t ^ nil =>• T.a(car(sres), . . . , cdr(sres))[t] = e ) 
(Vt:T, sres, ... :: t ^ nil =^ T.b(car(sres), ...)[?] = e > 

Figure 23: A sketch of the working formula after cleaning up equality antecedents 
and replacing abstraction functions with ones of larger arity, which affects DO, D2, 
D4, and D5. 

Note that since b does not depend on e , the new T.b has the same arity as the 
old T.b , but it throws away half of the first argument given to the old T.b . After 
applying /^-conversion to all of these A-expressions and applying the car and cdr 
of pairs according to (80), the working formula will have the form sketched in Fig- 
ure 23. Note that the substitutions we made affect all occurrences of abstraction 
functions, even those in pointwise axioms and rep axioms. 

Step 4: From Figure 23 to Figure 24. At this point, the first four lines of the 
sketch of the working formula in Figure 23 look like we want them to, but the 
other lines of the sketch do not. We choose to address rep axioms next. 
For any abstract variable a that depends on e in E , we calculate, 

(V t.T, sres, res. a, f :: t ^ nil =>• 

T.a(car(sres), res.a,f, cdr(sres))[t] = e ) 
= { rename dummy sres to a new name p ; note that e does not 

contain any occurrences of sres , since e is a user expression } 
( V t: T,p, res.a,f :: t ^ nil =>■ T.a(car($), res.a,f, cdr(p))[t] = e ) 
= { one-point rule to introduce sres and e (neither of 

which occurs free in the body of the rep axiom) for the 
expressions car(p) and cdr(p) } 
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(V f.T, p, res.a,f, sres, s :: t 7^ nil A sres = car(p) A e = cdr(p) =>■ 
T.a{sres, res.a,f, s)[t] = e } 
= { (80): pairing, car, and cdr } 

(V f.T, p, res.a,f, sres, s :: t 7^ nil A p = (sres,s) =>■ 
T.a{sres, res.a,f, s)[t] = e ) 
= { one-point rule to eliminate p } 

(V f.T, sres, res. a,f, s :: t 7^ nil =>• T.a(sres, res.a,f, s)[t] = e } 

This last line has the form of the corresponding rep axiom for a in X(VC D (m, C)) . 
For any abstract variable b that does not depend on s in E , we calculate, 

(V f.T, sres, res.b, g :: t nil =>• T.b{car{sres), res.b, g)[t] = e ) 
= { rename dummy sres to a new name p ; note that e does not 

contain any occurrences of sres , since e is a user expression } 
( W: res.b, g :: ? 7^ nil =>• T.b{car{p), res.b, g)[t] = e ) 
= { one-point rule to introduce sres and e (neither of 

which occurs free in the body of the rep axiom) for the 
expressions car{p) and cdr(p) } 
(V f.T, p, res.b, g, sres, s :: t 7^ nil A sres = car(p) A s = cdr(p) =^ 
T.b{sres, res.b, g)[t] = e ) 
= { (80): pairing, car, and cdr } 

(V f.T, p, res.b, g, sres, s :: t 7^ nil A p = (sres,s) =>• 
T.b{sres, res.b, g)[t] = e } 
= { one-point rule to eliminate p } 

( V f.T, sres, res.b, g, s :: t ^ nil =>• T.b{sres, res.b, g)[t] = e ) 
= { s does not occur free in the body of the quantification } 

( V f.T, sres, res.b, g :: t 7^ nil =>• T.b{sres, res.b, g)[t] = e ) 

This last line has the form of the corresponding rep axiom for b in X(VC D (m, C)) . 
Applying these transformations to every rep axiom in the working formula, we end 
up with a working formula whose shape is suggested by Figure 24. 

Step 5: From Figure 24 to Figure 25. For any abstract variable a that depends 
on s in E , we calculate, 

(V ' t, sres, sres, res. a, re's. a, f,f :: 

sres[t] = sres[t] A res.a[t] = res.a[t] A f[t] =f[t] =>• 
J-'.a(car(sres), res.a,f, cdr(sres))[t] = 
T.a{car{sres), res.a,f, cdr(sres))[t] ) 
= { rename dummies sres , sres to new names p , p } 
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DO: T.a(sfes, ...,£) 

T.b(sfes, . . .) 
Dl: (Ve :: (V sfes :: ... }} 

D2: (V? :: s = s =>• ( V sfes :: sfes = sfes =>• . . . }) 
D3: w:{Vs :: (sfes, e)[s] = (sfes, s)[s] v ...) 
D4: (y t, sfes, sfes, .. . :: sres[£] = sresl/] A . . . =>• 

T.a(car(sfes) , . . . , cdr(sfes))[t] = T.a(car(sfes), . . . , cdr(sfes))[t] ) 
(V t, sfes, sfes, .. . :: sfes[t] = sfes[t] A . . . =>• 
T.b(car(sfes), . . .)[t] = T.b(car(sfes), . . .)[t] ) 
D5: (Vt.T, sres, . . ., s :: t ^ nil =>• T.a(sres, . . . , e)[f] = e } 
( V?: T, 5re5, ... :: t # nil T.b(sres, ...)[?] = e }.. . 

Figure 24: A sketch of the working formula after massaging the rep axioms in 
Figure 23, which affects D5. 



(Vt,p,p, res.a, res.a,f,f :: 

p[t] = p[t] a res.a[t] = res.a[t] A f[t] =f[t] =^ 

T.a(car(p), res.a, f, cdr(p))[t] = T.a(car(p), res.a, f, cdr(p))[t] ) 
{ one-point rule to introduce sfes , sfes , s , and e as names for the 
car and cdr expressions } 
( V ' t,p, p, res.a, res.a, f,f, sfes, sfes, s, s :: 

sfes = car(p) A s = cdr(p) A sfes = car(p) A s = cdr(p) A 
p[t] = p[t] A res.a[t] = res.a[t] A f[t] =f[t] =^ 

F.a(sfes, res.a, f, s)[t] = T.a(sfes, res.a, f , s)[t] ) 
{ (80): pairing, car, and cdr } 
( V t,p,p, res.a, res.a, f,f, sfes, sfes, s, s :: 
p = (sfes, s) A p = (sfes, s) A 
pit] = p[t] A res.a[t] = res.a[t] A f[t] =f[t] =>• 

F.a(sfes, res.a, f, s)[t] = T.a(sfes, res.a, f , s)[t] ) 
{ one-point rule to eliminate p and p } 
( W, res.a, res.a,f,f, sfes, sfes, s, s :: 

(sfes, s)[t] = (sfes, s)[t] A res.a[t] = res.a[t] A f[t] =f[t] =^ 

F.a(sfes, res.a, f, s)[t] = T.a(sfes, res.a, f , e)[t] ) 
{ (81): pairing and select, and (79): pairing and equality } 
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( W, sres, sres, res.a, res.a, f,f, s, s :: 

sresit] = sresit] A res. ait] = res.a[t] A fit] =f[t] A sit] = sit] =>• 
T.a(sfes, res.a, f, s)[t] = T.a(sres, res.a, f, s)[t] ) 

This last line has the form of the pointwise axiom for T.a in X(VC D (m, Q) . For 
any abstract variable b that does not depend on e in E , we calculate, 

( V t, sres, sres, res.b, res.b, g, g :: 

sres[t] = sres[t] A res.b[t] = res.b[t] A g[t] = g[t] =^ 
F.bicarisres), res.b, g)[t] = T.b{car(sres), res.b, g)[t] } 
= { rename dummies sres , sres to new names p , p } 

{Vt,p,p, res.b, res.b, g,g :: 

pit] = Pit] A res.bit] = res.bit] A git] = git] =>• 
T.b{car(p), res.b, g)it] = T.b(car{p), res.b, g)it] ) 
= { one-point rule to introduce sres , sres , s , and e as names for 

car and cdr expressions } 
( y t, p, p, res.b, res.b, g, g, sres, sres, s, e :: 

sres = car(p) A s = cdr(p) A sres = car(p) A s = cdr(p) A 
Pit] = Pit] A res.bit] = res.bit] A git] = git] =>• 
T.b{sfes, res.b, g)it] = T.b{sres, res.b, g)it] ) 
= { (80): pairing, car , and cdr } 

( V t,p,p, res.b, res.b, g, g, sres, sres, s, s :: 
p = (sres, e) A p = {sres, s) A 
Pit] = Pit] A res.bit] = res.bit] A git] = git] =>• 
T.b{sfes, res.b, g)it] = T.b(sres, res.b, g)it] ) 
= { one-point rule to eliminate p and p } 

(V?, res.b, res.b, g, g, sres, sres, s, s :: 

(sres, s)it] = (sres, e)it] A res.bit] = res.bit] A git] = git] =^ 
T.b(sfes, res.b, g)it] = T.b(sres, res.b, g)it] ) 
= { (81): pairing and select, and (79): pairing and equality } 

(V?, sres, sres, res.b, res.b, g, g, s, e :: 

sresit] = sresit] A res.bit] = res.bit] A git] = git] A sit] = sit] =^ 
T.b(sfes, res.b, g)it] = T.b(sres, res.b, g)it] ) 
<^= { weaken antecedent } 
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DO: T.a(sfes, ...,£) 

T.b(sfes, . . .) 
Dl: (We :: (V sfes :: ... }} 

D2: (We :: e = e =>• (W sfes :: sres = sms =>■ . . . }) 
D3: w:(Vs :: (sfes, e)[s] = (sfes, e)[s] v ...} 

D4: (W t, sres, sfes, ... ,e, e :: sfes[t] = sfes[t] A ... A e[t] = e[t] =>• 
T.a(sfes, . . . , e)[t] = T.a(sfes, . . . , e)[t] } 
(V t, sres, sfes, .. . :: sres[t] = sfes[t] A . . . =>• 
T.b(sfes, . . .)[t] = T.b(sfes, . . .)[t] } 
D5: (Wf.T, sres, . . ., e :: t ^ nil =^ T.a(sres, . . . , e)[t] = e } 
(Wf.T, sres, ... :: t # nil =>• T.b(sres, ...)[?] = e } 

Figure 25: A sketch of the working formula after fixing up pointwise axioms from 
Figure 24, which affects D4. 

( V t, sres, sfes, res.b, res.b, g, g, e, e :: 

sfes[t] = sfes[t] A res.b[t] = res.b[t] A g[t] = g[t] =^ 
T.b(sfes, res.b, g)[t] = T.b(sfes, res.b, g)[t] ) 
= { e and e do not occur free in the body of the quantification } 

( V t, sres, sfes, res.b, res.b, g, g :: 

smsl/] = 5re5[?] A res.b[t] = res.b[t] A g[t] = g[t] =^ 
T.b(sfes, res.b, g)[t] = T.b(sfes, res.b, g)[t] } 

This last line has the form of the pointwise axiom for T.b in X(VC D (m, C)) . 
Applying these transformations for every abstract variable to the working formula, 
we end up with a working formula whose shape is suggested by Figure 25. The 
strengthening step we did in the calculation for T.b has the effect of weaking the 
working formula, since by characteristic VO, rep axioms appear only in negative 
positions. 

Step 6: From Figure 25 to Figure 26. We now have only one difference left 
between the working formula and formula X(VC D (m, C)) : shared-residue mod- 
ification constraints. Consider the elided disjunct of the modification constraint 
shown in Figure 25. According to V3 (page 87), each modification constraint for 
sres in VC D (m, C) has the form 

w:(W s :: sfes[s] = sfes[s] v F D (modpointv(sres,w, s)) ) 
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DO: T.a(sfes, . . . , e) 

T.b(sfes, . . .) 
Dl: (Ve :: (V sfes :: . . . }} 

D2: (Ve :: e = e =>• (V sfes :: sfes = sfes =>• . ..)> 
D3: w:(Vs :: sresls] = smsls] v ...) A modcon E (w, s, sres) 
D4: (V t, sfes, sfes, ... ,s, e :: sres|/] = sresl/] A ... A e|/] = s[t] =>• 
F.aisfes, . . . , s)[t] = T.a(sfes, . . . , e)[t] ) 
{y t, sfes, sfes, .. . :: sres!/] = sres!/] A ... =>• 
T.b{sfes, . . .)[t] = T.b{sfes, . . .)[t] } 
D5: (V f.T, sres, . . . , e :: t ^ nil =>• T.a(sres, . . . , s)[t] = e } 
( V/: 7, sra, ... :: t # nil =>• T.bisres, ...)[?] = e ) 

Figure 26: The final sketch of the working formula, which includes the transfor- 
mations of shared-residue modification constraints, which affect D3. 

for some w and 5 . Now that we've transformed the working formula into what 
looks like X(VC D (m, C)) except for modification constraints, we have trans- 
formed the elided F D (modpoint D (sres , w, s)) into X(F D (modpoint D (sres , w, s))) 
for which 

X(F D (modpoint D (sres , w, s))) 
{ (68): XoF D = F E } 
F E (modpointD(sres , w, s)) 
= { lemma (33) } 

F E (modpoint E (sres , w,s)) 

In summary, the elided disjunct of the modification constraint shown in Figure 25 
has the form F E (modpoint E (sres, w, s)) . We calculate, 

w:(V s :: (sfes, s)[s] = (sfes, s)[s] v F E (modpoint E (sres,w, s)) ) 
= { (81): pairing and select, and (79): pairing and equality } 

w:(Vs :: (sfes[s] = sfes[s] A e[s] = s[s]) v F E (modpoint E (sres,w, s)) ) 
= { distribute A , V , and V } 

w:(V s :: sra[j] = sfes[s] v F E (modpoint E (sres,w, s)) ) A 

w:(Vs :: s[s] = s[s] v F E (modpoint E (sres,w, s)) ) 
= { (24): definition of modcon E } 

w:(V s :: sra[i] = sfes[s] v F E (modpoint E (sres,w, s)) ) A 

modcon E (w, s, sres) 
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The last formula of this calculation has the form of shared-residue modifica- 
tion constraints in XiVCoim, C)) , see D3 of Figure 18. Applying this trans- 
formation to the working formula, we end up with a working formula whose 
shape is suggested by Figure 26, which agrees on all accounts with the formula 
X(VC D (m, Q) . In summary, we have performed validity preserving steps that 
transform formula VC D (m, C) into formula X(VC D (m, C)) . 

Tah-dah, we have proved X property (75), and thus also the Soundness Theo- 
rem. B 



Part IV 

Epilogue 

We conclude with a few miscellaneous observations about our theorem and proof. 

Length. We can easily imagine readers who doubt the utility of an 80-page 
proof. One purpose of a proof is to persuade. With an eye to this purpose, we 
placed the informal arguments to Soundness Lemma C as early as possible. An- 
other purpose of a proof is to reveal errors. Regarding this purpose, we can report 
that our proof has already demonstrated its value: an earlier attempted proof came 
to ground on Saxe's counterexample in Section 6.3. Of course, we would be de- 
lighted to learn of a shorter proof. 

Limitations of the VC generator. Observant readers may have noticed that the 
verification condition generator that we have proved to be modularly sound does 
not include the refinements explained in Section 8. That is, it does not allow 
"freeconditions" or "free modification of unused state". We suspect that we could 
remedy these limitations of the proof without major changes, but we have not 
checked the details. 

Names of adornments. For most of the proof, it seems to make things easier 
if the number of different adornments is kept small. For example, this means 
that definition (24) of modcon can hard- wire the pre- and post-adornments x and 
x , rather than taking them as additional parameters. But to apply the Chain of 
Equalities Lemma (page 113), we need to rename variables so that each genera- 
tion of variables has its own unique adornment. As the Chain Rewriting Lemma 
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(page 124), its proof, and the proof of the Chain of Equalities Corollary (page 127) 
show, this takes some effort. 

The inclusion of Soundness Lemma D. The specialization Soundness Lemma D 
of the Soundness Theorem applies when the difference between scopes D and E 
is one abstract field declaration and a number of dependency declarations on that 
field. By including this lemma, the definition of X (Figure 17, page 134) can as- 
sume e to be concrete. This means that various applications of F E to expressions 
involving s can be omitted in the definition of X , since F E is the identity on 
concrete fields. This appears to reduce clutter in the proofs of the X properties, 
especially in the proof of X property (75) in Section A32. It also means that the 
proof of Soundness Lemma D, which uses Soundness Lemma C whose proof uses 
X and its properties, focuses only on the differences of the field e being abstract 
versus it being concrete. 

Selection determines maps. In the proofs of the Chain of Equalities Lemma 
(page 113) and the Chain Rewriting Lemma (page 124), we use axiom (44) (specif- 
ically, on pages 115 and 123), which says that two maps are equal if all of their 
elements are. In other words, there is no other feature of maps that distinguishes 
them. While we don't see anything wrong with using this axiom about select in 
our soundness proof, it is interesting that in our experience with applying ESC 
to real systems programs, we have not found a need to provide this axiom to the 
theorem prover. Stated differently, although our soundness proof relies on this 
axiom, whether or not the verification conditions we produce hold does not seem 
to rely on this axiom. 

Selection on map pairs. The proof of X property (75) in Section A32 intro- 
duces three functions (pairing, car, and cdr) and postulates three axioms about 
these functions. (To be suggestive, these functions have familiar names, but they 
should nevertheless be considered to be fresh function symbols that do not clash 
with other interpreted or uninterpreted function symbols in the user language.) 

The first of these axioms, (79), seems in no way controversial. 

The second axiom, (80), is not controversial in its "only if" direction. The 
"if" direction implies that car and cdr are total functions that return two pieces 
a and b whose pairing is again p . Thus, there are no indivisible "atoms" on 
which car and cdr are not defined: everything is a "pair". 
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The third axiom, (81) relates the pairing and the previously defined function 
select. This may appear to lie beyond more usual, "trusted" axioms. 

The fact that these axioms, and select axiom (44) for that matter, are used in the 
proof means in general that they should always appear in the background predicate 
as things that one can use to prove or disprove a verification condition. However, 
if one can prove that these axioms are a conservative extension of the select and 
stores axioms (43), then they need not be included in the background predicate. 
Being a conservative extension means that their inclusion does not allow one to 
prove more things about relevant formulas (in particular, generated verification 
conditions) that do not contain the new function symbols than one could without 
the additional axioms. 

We have not proved that these axioms are a conservative extension. In fact, we 
know that, in general, they are not. In particular, if one mixes maps and non-maps 
(for example, by using an integer as the first argument to select), then one can find 
counterexamples that show that these axioms are not a conservative extension. 
However, by considering a multi-sorted logic that distinguishes between maps and 
non-maps, then the counterexamples we know do not apply. In such a multi-sorted 
logic, one needs two sets of the three functions in Section A32. The signatures of 
these functions would be 

select: Map x NonMap — > NonMap 
store: Map x NonMap x NonMap - 
mappair: Map x Map —> Map 
mapcar: Map — > Map 
mapcdr: Map — > Map 
nonmappair: NonMap x NonMap — 
nonmapcar: NonMap —> NonMap 
nonmapcdr: NonMap — > NonMap 

We claim our VC generation to be consistent with these signatures. In the multi- 
sorted logic, axioms (79) and (80) would be duplicated, once for each set of pair- 
ing functions, and axiom (81) would be written 

( V a: Map, b: Map, t: NonMap :: 

mappair (a, b)[t] = nonmappair (a[t], b[t]) ) 

We do not know whether or not these functions and axioms are a conservative 
extension in such a multi-sorted logic. 



Map 



NonMap 
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Use of modularity requirements and residues in the proof. As motivated in 
Sections 6 and 7.2, the soundness of modular verification relies crucially on the 
modularity requirements and the use of residue variables in the VC generation. So 
where are these actually used in the proof? 

The visibility and top-down requirements are used in the proof of lemma (29). 
This lemma is used to prove lemma (32), which in turn proves lemma (33), which 
is used in two places. First, lemma (33) proves the three-part lemma (76)-(77)- 
(78), which in turn is used to prove the X properties (72) and (73). Second, lemma 
(33) is used in the proof of X property (75). 

The visibility requirement is also used in the first case in the proof of Sound- 
ness Lemma F and the top-down requirement is used in the second case of that 
proof. 

Residues appear more ubiquitously in the proof, but the lemma that cannot be 
proved without them is Soundness Lemma C. More precisely, individual residue 
variables are vital to the Chain of Equalities Corollary (page 127) and shared 
residue variables are vital to X property (75). 
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